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

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

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

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


当前回答

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

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

其他回答

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

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 

如果速度是您的唯一目标,那么使用int常量来标识子类似乎可以节省几毫秒的时间

static final int ID_A = 0;
static final int ID_B = 1;
abstract class Base {
  final int id;
  Base(int i) { id = i; }
}
class A extends Base {
 A() { super(ID_A); }
}
class B extends Base {
 B() { super(ID_B); }
}
...
Base obj = ...
switch(obj.id) {
case  ID_A: .... break;
case  ID_B: .... break;
}

糟糕的OO设计,但如果你的性能分析表明这是你的瓶颈,那么也许。在我的代码中,分派代码占用了总执行时间的10%,这可能有助于1%的总速度提高。

我基于jmh-java-benchmark- prototype:2.21编写了一个性能测试。JDK为openjdk, version为1.8.0_212。测试机器是mac pro。 测试结果为:

Benchmark                Mode  Cnt    Score   Error   Units
MyBenchmark.getClasses  thrpt   30  510.818 ± 4.190  ops/us
MyBenchmark.instanceOf  thrpt   30  503.826 ± 5.546  ops/us

结果表明:getClass优于instanceOf,这与其他测试结果相反。然而,我不知道为什么。

测试代码如下:

public class MyBenchmark {

public static final Object a = new LinkedHashMap<String, String>();

@Benchmark
@BenchmarkMode(Mode.Throughput)
@OutputTimeUnit(TimeUnit.MICROSECONDS)
public boolean instanceOf() {
    return a instanceof Map;
}

@Benchmark
@BenchmarkMode(Mode.Throughput)
@OutputTimeUnit(TimeUnit.MICROSECONDS)
public boolean getClasses() {
    return a.getClass() == HashMap.class;
}

public static void main(String[] args) throws RunnerException {
    Options opt =
        new OptionsBuilder().include(MyBenchmark.class.getSimpleName()).warmupIterations(20).measurementIterations(30).forks(1).build();
    new Runner(opt).run();
}
}

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

很难说一个特定的JVM是如何实现实例的,但在大多数情况下,对象与结构相当,类也是如此,每个对象结构都有一个指向它是实例的类结构的指针。实际上是instanceof for

if (o instanceof java.lang.String)

可能和下面的C代码一样快

if (objectStruct->iAmInstanceOf == &java_lang_String_class)

假设JIT编译器已经就位,并且工作出色。

考虑到这只是访问一个指针,在指针指向的某个偏移量处获得一个指针,并将其与另一个指针进行比较(这基本上与测试32位数字是否相等相同),我认为操作实际上可以非常快。

但是,这并不一定是必须的,它在很大程度上取决于JVM。但是,如果这将成为代码中的瓶颈操作,我认为JVM实现相当糟糕。即使没有JIT编译器,只解释代码,也应该能够在几乎没有时间的情况下创建一个实例测试。