我正在开发一个应用程序,其中一个设计方法涉及到大量使用instanceof操作符。虽然我知道OO设计通常试图避免使用instanceof,但那是另一回事,这个问题纯粹与性能有关。我想知道是否对性能有影响?和==一样快吗?

例如,我有一个有10个子类的基类。在接受基类的单个函数中,我检查类是否是子类的实例并执行一些例程。

我想到的另一种解决方法是使用“type id”整数原语,并使用位掩码来表示子类的类别,然后对子类“type id”与表示类别的常量掩码进行位掩码比较。

instanceof是否被JVM优化得更快?我想坚持使用Java,但应用程序的性能至关重要。如果有人曾经在这条路上走过,可以提供一些建议,那就太棒了。我是不是太挑剔了,或者专注在错误的地方去优化?


当前回答

'instanceof'实际上是一个运算符,就像+或-,我相信它有自己的JVM字节码指令。应该够快了。

我不应该说,如果你有一个开关,你正在测试一个对象是否是某个子类的实例,那么你的设计可能需要重做。考虑将特定于子类的行为下推到子类本身。

其他回答

现代JVM/JIT编译器已经消除了大多数传统的“慢”操作对性能的影响,包括instanceof、异常处理、反射等。

正如Donald Knuth所写的,“我们应该忘记小的效率,大约97%的时候:过早的优化是万恶之源。”instanceof的性能可能不是问题,所以在确定问题所在之前,不要浪费时间想出奇异的解决方案。

一般来说,在这种情况下(instanceof检查这个基类的子类)不支持使用“instanceof”操作符的原因是,您应该做的是将操作移动到一个方法中,并为适当的子类重写它。例如,如果你有:

if (o instanceof Class1)
   doThis();
else if (o instanceof Class2)
   doThat();
//...

你可以用

o.doEverything();

然后在Class1中调用“doEverything()”的实现,在Class2中调用“doThat()”,以此类推。

方法

我写了一个基准程序来评估不同的实现:

实例实现(作为参考) 通过抽象类和@Override测试方法实现面向对象 使用自己的类型实现 getClass() == _.class实现

我使用jmh运行了100个预热调用、1000个测试迭代和10个分支的基准测试。因此,每个选项都测量了10,000次,在我的MacBook Pro上运行macOS 10.12.4和Java 1.8的整个基准测试需要12:18:57。该基准衡量每个选项的平均时间。要了解更多细节,请参阅我在GitHub上的实现。

为了完整起见:这个答案和我的基准有一个以前的版本。

结果

| Operation  | Runtime in nanoseconds per operation | Relative to instanceof |
|------------|--------------------------------------|------------------------|
| INSTANCEOF | 39,598 ± 0,022 ns/op                 | 100,00 %               |
| GETCLASS   | 39,687 ± 0,021 ns/op                 | 100,22 %               |
| TYPE       | 46,295 ± 0,026 ns/op                 | 116,91 %               |
| OO         | 48,078 ± 0,026 ns/op                 | 121,42 %               |

博士tl;

在Java 1.8中,instanceof是最快的方法,尽管getClass()非常接近。

我也更喜欢枚举方法,但我将使用抽象基类强制子类实现getType()方法。

public abstract class Base
{
  protected enum TYPE
  {
    DERIVED_A, DERIVED_B
  }

  public abstract TYPE getType();

  class DerivedA extends Base
  {
    @Override
    public TYPE getType()
    {
      return TYPE.DERIVED_A;
    }
  }

  class DerivedB extends Base
  {
    @Override
    public TYPE getType()
    {
      return TYPE.DERIVED_B;
    }
  }
}

在大多数现实世界的实现中(也就是说,在真正需要instanceof的实现中,您不能像每个初学者教科书和上面的Demian所建议的那样,通过重写一个通用方法来解决它),instanceof可能会比简单的等号更昂贵。

为什么呢?因为可能会发生的情况是,你有几个接口,它们提供了一些功能(比如,接口x, y和z),以及一些要操作的对象,这些对象可能(或不)实现其中一个接口……但不是直接的。例如,我有:

W扩展x

A实现了w

B延伸A

C扩展B,实现y

D扩展C,实现z

假设我正在处理D的一个实例,对象D . Computing (D instanceof x)需要采用d.getClass(),循环通过它实现的接口来知道是否一个是==到x,如果不是这样做,再次递归为它们的所有祖先… 在我们的例子中,如果你对那棵树进行宽度优先的探索,假设y和z没有扩展任何东西,至少会产生8个比较……

现实世界的推导树的复杂性可能更高。在某些情况下,JIT可以优化其中的大部分,如果它能够在所有可能的情况下,将d解析为扩展x的某个实例。然而,实际上,您大部分时间都将遍历该树。

如果这成为一个问题,我建议使用处理程序映射,将对象的具体类链接到进行处理的闭包。它删除了树遍历阶段,以支持直接映射。但是,要注意,如果你为C.class设置了一个处理程序,上面的对象d将不会被识别。

这是我的2美分,我希望他们能帮助…