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

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

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

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


当前回答

InstanceOf是一个糟糕的面向对象设计的警告。

当前的jvm意味着instanceOf本身并不是一个性能问题。如果您发现自己经常使用它,特别是在核心功能方面,那么可能是时候考虑一下设计了。重构为更好的设计所带来的性能(和简单性/可维护性)收益将大大超过实际instanceOf调用所花费的实际处理器周期。

给出一个非常简单的编程示例。

if (SomeObject instanceOf Integer) {
  [do something]
}
if (SomeObject instanceOf Double) {
  [do something different]
}

是一个糟糕的架构,更好的选择是让SomeObject成为两个子类的父类,其中每个子类重写一个方法(doSomething),这样代码看起来就像这样:

Someobject.doSomething();

其他回答

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;
    }
  }
}

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

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

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

我认为在本页提交一个反例来反驳“instanceof”的普遍共识是值得的。我发现我在一个内循环中有一些代码(在一些历史性的优化尝试中)

if (!(seq instanceof SingleItem)) {
  seq = seq.head();
}

在SingleItem上调用head()返回的值不变。将代码替换为

seq = seq.head();

让我从269毫秒加速到169ms,尽管事实上在循环中发生了一些相当繁重的事情,比如字符串到双精度转换。当然,加速可能更多是由于消除了条件分支,而不是消除了操作符本身的实例;但我觉得值得一提。