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

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

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

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


当前回答

关于Peter Lawrey的注释,final类不需要instanceof,只需使用一个引用相等,请小心!即使最终的类不能扩展,也不能保证它们由相同的类加载器加载。只有在绝对肯定这段代码只有一个类加载器时,才使用x.getClass() == SomeFinal.class或类似的类加载器。

其他回答

方法

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

实例实现(作为参考) 通过抽象类和@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()非常接近。

将决定性能影响的项目有:

The number of possible classes for which the instanceof operator could return true The distribution of your data - are most of the instanceof operations resolved in the first or second attempt? You'll want to put your most likely to return true operations first. The deployment environment. Running on a Sun Solaris VM is significantly different than Sun's Windows JVM. Solaris will run in 'server' mode by default, while Windows will run in client mode. The JIT optimizations on Solaris, will make all method access able the same.

我为四种不同的分派方法创建了一个微基准测试。Solaris的结果如下所示,数值越小越快:

InstanceOf 3156
class== 2925 
OO 3083 
Id 3067 

回答你的最后一个问题:除非分析人员告诉你,你在某个实例上花费了大量的时间:是的,你在吹毛求疵。

在考虑优化从来不需要优化的东西之前:以最易读的方式编写算法并运行它。运行它,直到jit编译器有机会优化它自己。如果这段代码有问题,可以使用分析器来告诉您,在哪里可以获得最大收益并进行优化。

在高度优化编译器的时代,您对瓶颈的猜测很可能是完全错误的。

在这个答案的真正精神(我完全相信):一旦jit编译器有机会优化它,我绝对不知道instanceof和==是如何关联的。

我忘了:永远不要测量第一次运行。

我也更喜欢枚举方法,但我将使用抽象基类强制子类实现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;
    }
  }
}

I'll get back to you on instanceof performance. But a way to avoid problem (or lack thereof) altogether would be to create a parent interface to all the subclasses on which you need to do instanceof. The interface will be a super set of all the methods in sub-classes for which you need to do instanceof check. Where a method does not apply to a specific sub-class, simply provide a dummy implementation of this method. If I didn't misunderstand the issue, this is how I've gotten around the problem in the past.