我正在开发一个应用程序，其中一个设计方法涉及到大量使用instanceof操作符。虽然我知道OO设计通常试图避免使用instanceof，但那是另一回事，这个问题纯粹与性能有关。我想知道是否对性能有影响?和==一样快吗?
例如，我有一个有10个子类的基类。在接受基类的单个函数中，我检查类是否是子类的实例并执行一些例程。
我想到的另一种解决方法是使用“type id”整数原语，并使用位掩码来表示子类的类别，然后对子类“type id”与表示类别的常量掩码进行位掩码比较。
instanceof是否被JVM优化得更快?我想坚持使用Java，但应用程序的性能至关重要。如果有人曾经在这条路上走过，可以提供一些建议，那就太棒了。我是不是太挑剔了，或者专注在错误的地方去优化?
当前回答
Instanceof非常快。它可以归结为用于类引用比较的字节码。在一个循环中尝试几百万个实例，自己看看。
其他回答
如果它确实是项目中的性能问题，您应该进行测量/分析。如果是的话，我建议重新设计——如果可能的话。我很确定你不能打败平台的本机实现(用C编写)。在这种情况下，你还应该考虑多重继承。
你应该告诉更多关于这个问题，也许你可以使用一个关联存储，例如Map<Class，对象>如果你只对具体类型感兴趣。
Instanceof非常快。它可以归结为用于类引用比较的字节码。在一个循环中尝试几百万个实例，自己看看。
我认为在本页提交一个反例来反驳“instanceof”的普遍共识是值得的。我发现我在一个内循环中有一些代码(在一些历史性的优化尝试中)
if (!(seq instanceof SingleItem)) {
seq = seq.head();
}
在SingleItem上调用head()返回的值不变。将代码替换为
seq = seq.head();
让我从269毫秒加速到169ms，尽管事实上在循环中发生了一些相当繁重的事情，比如字符串到双精度转换。当然，加速可能更多是由于消除了条件分支，而不是消除了操作符本身的实例;但我觉得值得一提。
InstanceOf是一个糟糕的面向对象设计的警告。
当前的jvm意味着instanceOf本身并不是一个性能问题。如果您发现自己经常使用它，特别是在核心功能方面，那么可能是时候考虑一下设计了。重构为更好的设计所带来的性能(和简单性/可维护性)收益将大大超过实际instanceOf调用所花费的实际处理器周期。
给出一个非常简单的编程示例。
if (SomeObject instanceOf Integer) {
[do something]
}
if (SomeObject instanceOf Double) {
[do something different]
}
是一个糟糕的架构，更好的选择是让SomeObject成为两个子类的父类，其中每个子类重写一个方法(doSomething)，这样代码看起来就像这样:
Someobject.doSomething();
将决定性能影响的项目有:
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
