我正在开发一个应用程序，其中一个设计方法涉及到大量使用instanceof操作符。虽然我知道OO设计通常试图避免使用instanceof，但那是另一回事，这个问题纯粹与性能有关。我想知道是否对性能有影响?和==一样快吗?
例如，我有一个有10个子类的基类。在接受基类的单个函数中，我检查类是否是子类的实例并执行一些例程。
我想到的另一种解决方法是使用“type id”整数原语，并使用位掩码来表示子类的类别，然后对子类“type id”与表示类别的常量掩码进行位掩码比较。
instanceof是否被JVM优化得更快?我想坚持使用Java，但应用程序的性能至关重要。如果有人曾经在这条路上走过，可以提供一些建议，那就太棒了。我是不是太挑剔了，或者专注在错误的地方去优化?
当前回答
如果速度是您的唯一目标，那么使用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%的总速度提高。
其他回答
现代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()”，以此类推。
德米安和保罗提到了一个很好的观点;然而，要执行的代码的位置实际上取决于你想如何使用数据……
我非常喜欢可以以多种方式使用的小型数据对象。如果你采用覆盖(多态)方法，你的对象只能被“一种方式”使用。
这就是模式发挥作用的地方……
您可以使用双重分派(如在访问者模式中)要求每个对象传递自身“调用您”——这将解析对象的类型。但是(再次)，您需要一个可以对所有可能的子类型“做一些事情”的类。
我更喜欢使用策略模式，在这种模式下，您可以为想要处理的每个子类型注册策略。大致如下。注意，这只有助于精确的类型匹配，但它具有可扩展的优势——第三方贡献者可以添加自己的类型和处理程序。(这对于OSGi这样的动态框架很好，可以添加新的包)
希望这能激发一些其他的想法……
package com.javadude.sample;
import java.util.HashMap;
import java.util.Map;
public class StrategyExample {
static class SomeCommonSuperType {}
static class SubType1 extends SomeCommonSuperType {}
static class SubType2 extends SomeCommonSuperType {}
static class SubType3 extends SomeCommonSuperType {}
static interface Handler<T extends SomeCommonSuperType> {
Object handle(T object);
}
static class HandlerMap {
private Map<Class<? extends SomeCommonSuperType>, Handler<? extends SomeCommonSuperType>> handlers_ =
new HashMap<Class<? extends SomeCommonSuperType>, Handler<? extends SomeCommonSuperType>>();
public <T extends SomeCommonSuperType> void add(Class<T> c, Handler<T> handler) {
handlers_.put(c, handler);
}
@SuppressWarnings("unchecked")
public <T extends SomeCommonSuperType> Object handle(T o) {
return ((Handler<T>) handlers_.get(o.getClass())).handle(o);
}
}
public static void main(String[] args) {
HandlerMap handlerMap = new HandlerMap();
handlerMap.add(SubType1.class, new Handler<SubType1>() {
@Override public Object handle(SubType1 object) {
System.out.println("Handling SubType1");
return null;
} });
handlerMap.add(SubType2.class, new Handler<SubType2>() {
@Override public Object handle(SubType2 object) {
System.out.println("Handling SubType2");
return null;
} });
handlerMap.add(SubType3.class, new Handler<SubType3>() {
@Override public Object handle(SubType3 object) {
System.out.println("Handling SubType3");
return null;
} });
SubType1 subType1 = new SubType1();
handlerMap.handle(subType1);
SubType2 subType2 = new SubType2();
handlerMap.handle(subType2);
SubType3 subType3 = new SubType3();
handlerMap.handle(subType3);
}
}
将决定性能影响的项目有:
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
我认为在本页提交一个反例来反驳“instanceof”的普遍共识是值得的。我发现我在一个内循环中有一些代码(在一些历史性的优化尝试中)
if (!(seq instanceof SingleItem)) {
seq = seq.head();
}
在SingleItem上调用head()返回的值不变。将代码替换为
seq = seq.head();
让我从269毫秒加速到169ms，尽管事实上在循环中发生了一些相当繁重的事情，比如字符串到双精度转换。当然，加速可能更多是由于消除了条件分支，而不是消除了操作符本身的实例;但我觉得值得一提。
