小开

最佳答案

现代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()”，以此类推。

小开

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

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

小开

Instanceof非常快。它可以归结为用于类引用比较的字节码。在一个循环中尝试几百万个实例，自己看看。

小开

如果它确实是项目中的性能问题，您应该进行测量/分析。如果是的话，我建议重新设计——如果可能的话。我很确定你不能打败平台的本机实现(用C编写)。在这种情况下，你还应该考虑多重继承。

你应该告诉更多关于这个问题，也许你可以使用一个关联存储，例如Map<类，对象>如果你只对具体类型感兴趣。

小开

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

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

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

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

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

小开

你关注错了。instanceof和检查相同内容的任何其他方法之间的差异甚至可能无法测量。如果性能是关键，那么Java可能是错误的语言。主要原因是您无法控制VM何时决定要去收集垃圾，在大型程序中，这可能会使CPU在几秒钟内达到100% (MagicDraw 10在这方面非常出色)。除非你能控制运行这个程序的每台计算机，否则你无法保证它会运行在哪个版本的JVM上，而且很多老版本的JVM都存在严重的速度问题。如果这是一个小的应用程序，你可能对Java还行，但如果你不断地读取和丢弃数据，那么你将注意到GC开始。

小开

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

if (o instanceof java.lang.String)

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

if (objectStruct->iAmInstanceOf == &java_lang_String_class)

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

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

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

小开

运算符是一个糟糕的面向对象设计的警告。

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

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

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

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

Someobject.doSomething();

小开

在现代Java版本中，instanceof操作符作为一个简单的方法调用更快。这意味着:

if(a instanceof AnyObject){
}

为:

if(a.getType() == XYZ){
}

另一件事是如果你需要级联许多instanceof。然后，只调用一次getType()的切换会更快。

小开

德米安和保罗提到了一个很好的观点;然而，要执行的代码的位置实际上取决于你想如何使用数据…

我非常喜欢可以以多种方式使用的小型数据对象。如果你采用覆盖(多态)方法，你的对象只能被“一种方式”使用。

这就是模式发挥作用的地方……

您可以使用双重分派(如在访问者模式中)要求每个对象传递自身“调用您”——这将解析对象的类型。然而(再次)，你将需要一个可以对所有可能的子类型“做事情”的类。

我更喜欢使用策略模式，在这种模式下，您可以为想要处理的每个子类型注册策略。大致如下。注意，这只有助于精确的类型匹配，但它具有可扩展的优势——第三方贡献者可以添加自己的类型和处理程序。(这对于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);
}
}

小开

我只是做了一个简单的测试，看看instanceOf的性能如何与对一个只有一个字母的字符串对象的简单s.equals()调用进行比较。

在10.000.000循环中，instanceOf给了我63-96ms，而字符串equals给了我106-230ms

我使用java jvm 6。

所以在我的简单测试中，做一个instanceOf而不是一个字符串比较更快。

使用Integer的.equals()而不是string的给了我相同的结果，只有当我使用== I比instanceOf快20ms(在10.000.000循环中)

小开

在大多数现实世界的实现中(也就是说，在真正需要instanceof的实现中，您不能像每个初学者教科书和上面的Demian所建议的那样，通过重写一个通用方法来解决它)，instanceof可能会比简单的等号更昂贵。

为什么呢?因为可能会发生的情况是，你有几个接口，它们提供了一些功能(比如，接口x, y和z)，以及一些要操作的对象，这些对象可能(或不)实现其中一个接口……但不是直接的。例如，我有:

W扩展x

A实现了w

B延伸A

C扩展B，实现y

D扩展C，实现z

假设我正在处理D的一个实例，对象D . Computing (D instanceof x)需要采用d.getClass()，循环通过它实现的接口来知道是否一个是==到x，如果不是这样做，再次递归为它们的所有祖先… 在我们的例子中，如果对该树进行宽度优先探索，假设y和z不扩展任何内容，将产生至少8个比较…

现实世界的推导树的复杂性可能更高。在某些情况下，JIT可以优化其中的大部分，如果它能够在所有可能的情况下，将d解析为扩展x的某个实例。然而，实际上，您大部分时间都将遍历该树。

如果这成为一个问题，我建议使用处理程序映射，将对象的具体类链接到进行处理的闭包。它删除了树遍历阶段，以支持直接映射。但是，要注意，如果你为C.class设置了一个处理程序，上面的对象d将不会被识别。

这是我的2美分，我希望他们能帮助…

小开

instanceof非常有效，因此您的性能不太可能受到影响。然而，使用大量的instanceof暗示了一个设计问题

如果您可以使用xClass == String.class，这将更快。注意:final类不需要instanceof。

小开

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

小开

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

instanceof操作符可能返回true的类的数目
数据的分布——大多数实例操作是在第一次或第二次尝试中解决的吗?你会想把最有可能返回真值的运算放在前面。
部署环境。在Sun Solaris VM上运行与Sun的Windows JVM有很大不同。Solaris将默认以“服务器”模式运行，而Windows将以客户端模式运行。Solaris上的JIT优化将使所有方法访问都是相同的。

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

InstanceOf 3156
class== 2925
OO 3083
Id 3067

小开

instanceof真的很快，只需要几个CPU指令。

显然，如果一个类X没有加载子类(JVM知道)，instanceof可以被优化为:

     x instanceof X
==>  x.getClass()==X.class
==>  x.classID == constant_X_ID

主要的花费只是阅读!

如果X确实加载了子类，则需要更多的读取操作;他们可能住在一起，所以额外的费用也很低。

大家好!

小开

如果速度是您的唯一目标，那么使用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%的总速度提高。

小开

我有同样的问题，但因为我没有找到类似于我的用例的“性能指标”，我做了一些更多的示例代码。在我的硬件和Java 6 &7, instanceof和switch在1000万次迭代时的差异是

for 10 child classes - instanceof: 1200ms vs switch: 470ms
for 5 child classes  - instanceof:  375ms vs switch: 204ms

因此，instanceof确实比较慢，特别是在大量的if-else-if语句上，但是在实际应用中差异可以忽略不计。

import java.util.Date;


public class InstanceOfVsEnum {


public static int c1, c2, c3, c4, c5, c6, c7, c8, c9, cA;


public static class Handler {
public enum Type { Type1, Type2, Type3, Type4, Type5, Type6, Type7, Type8, Type9, TypeA }
protected Handler(Type type) { this.type = type; }
public final Type type;


public static void addHandlerInstanceOf(Handler h) {
if( h instanceof H1) { c1++; }
else if( h instanceof H2) { c2++; }
else if( h instanceof H3) { c3++; }
else if( h instanceof H4) { c4++; }
else if( h instanceof H5) { c5++; }
else if( h instanceof H6) { c6++; }
else if( h instanceof H7) { c7++; }
else if( h instanceof H8) { c8++; }
else if( h instanceof H9) { c9++; }
else if( h instanceof HA) { cA++; }
}


public static void addHandlerSwitch(Handler h) {
switch( h.type ) {
case Type1: c1++; break;
case Type2: c2++; break;
case Type3: c3++; break;
case Type4: c4++; break;
case Type5: c5++; break;
case Type6: c6++; break;
case Type7: c7++; break;
case Type8: c8++; break;
case Type9: c9++; break;
case TypeA: cA++; break;
}
}
}


public static class H1 extends Handler { public H1() { super(Type.Type1); } }
public static class H2 extends Handler { public H2() { super(Type.Type2); } }
public static class H3 extends Handler { public H3() { super(Type.Type3); } }
public static class H4 extends Handler { public H4() { super(Type.Type4); } }
public static class H5 extends Handler { public H5() { super(Type.Type5); } }
public static class H6 extends Handler { public H6() { super(Type.Type6); } }
public static class H7 extends Handler { public H7() { super(Type.Type7); } }
public static class H8 extends Handler { public H8() { super(Type.Type8); } }
public static class H9 extends Handler { public H9() { super(Type.Type9); } }
public static class HA extends Handler { public HA() { super(Type.TypeA); } }


final static int cCycles = 10000000;


public static void main(String[] args) {
H1 h1 = new H1();
H2 h2 = new H2();
H3 h3 = new H3();
H4 h4 = new H4();
H5 h5 = new H5();
H6 h6 = new H6();
H7 h7 = new H7();
H8 h8 = new H8();
H9 h9 = new H9();
HA hA = new HA();


Date dtStart = new Date();
for( int i = 0; i < cCycles; i++ ) {
Handler.addHandlerInstanceOf(h1);
Handler.addHandlerInstanceOf(h2);
Handler.addHandlerInstanceOf(h3);
Handler.addHandlerInstanceOf(h4);
Handler.addHandlerInstanceOf(h5);
Handler.addHandlerInstanceOf(h6);
Handler.addHandlerInstanceOf(h7);
Handler.addHandlerInstanceOf(h8);
Handler.addHandlerInstanceOf(h9);
Handler.addHandlerInstanceOf(hA);
}
System.out.println("Instance of - " + (new Date().getTime() - dtStart.getTime()));


dtStart = new Date();
for( int i = 0; i < cCycles; i++ ) {
Handler.addHandlerSwitch(h1);
Handler.addHandlerSwitch(h2);
Handler.addHandlerSwitch(h3);
Handler.addHandlerSwitch(h4);
Handler.addHandlerSwitch(h5);
Handler.addHandlerSwitch(h6);
Handler.addHandlerSwitch(h7);
Handler.addHandlerSwitch(h8);
Handler.addHandlerSwitch(h9);
Handler.addHandlerSwitch(hA);
}
System.out.println("Switch of - " + (new Date().getTime() - dtStart.getTime()));
}
}

小开

我会在绩效情况下给你答复的。但是一种完全避免问题(或缺乏问题)的方法是为需要执行instanceof的所有子类创建父接口。该接口将是所有的超集，这些方法在子类中需要进行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;
}
}
}

小开

方法

我写了基准程序来计算不同的实现:

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

小开

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

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

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

seq = seq.head();

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

小开

我写了一个基于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();
}
}

在Java中使用instanceof对性能的影响

方法

结果

博士tl;