В чем разница между instanceof и Class.isAssignableFrom ()?

При использовании instanceof вам необходимо знать класс B во время компиляции. При использовании isAssignableFrom() он может быть динамическим и изменяться во время выполнения.

instanceof можно использовать только со ссылочными типами, но не с примитивными типами. isAssignableFrom() можно использовать с любыми объектами класса:

a instanceof int  // syntax error
3 instanceof Foo  // syntax error
int.class.isAssignableFrom(int.class)  // true

См. http://java.sun.com/javase/6/docs/api/java/lang/Class.html#isAssignableFrom(java.lang.Class).

Если говорить о производительности:

TL; DR

Используйте isInstance или instanceof с аналогичной производительностью. isAssignableFrom немного медленнее.

По производительности:

1. isInstance
2. instanceof (+ 0,5%)
3. isAssignableFrom (+ 2,7%)

На основе теста производительности 2000 итераций на JAVA 8 Windows x64 с 20 итерациями разминки.

Теоретически

Используя такую ​​программу, как просмотрщик байт-кода, мы можем преобразовать каждый оператор в байт-код.

В контексте:

package foo;

public class Benchmark
{
  public static final Object a = new A();
  public static final Object b = new B();

  ...

}

ЯВА:

b instanceof A;

Байт-код:

getstatic foo/Benchmark.b:java.lang.Object
instanceof foo/A

ЯВА:

A.class.isInstance(b);

Байт-код:

ldc Lfoo/A; (org.objectweb.asm.Type)
getstatic foo/Benchmark.b:java.lang.Object
invokevirtual java/lang/Class isInstance((Ljava/lang/Object;)Z);

ЯВА:

A.class.isAssignableFrom(b.getClass());

Байт-код:

ldc Lfoo/A; (org.objectweb.asm.Type)
getstatic foo/Benchmark.b:java.lang.Object
invokevirtual java/lang/Object getClass(()Ljava/lang/Class;);
invokevirtual java/lang/Class isAssignableFrom((Ljava/lang/Class;)Z);

Измеряя, сколько инструкций байт-кода используется каждым оператором, мы могли ожидать, что instanceof и isInstance будут быстрее, чем isAssignableFrom. Однако фактическая производительность определяется НЕ байт-кодом, а машинным кодом (который зависит от платформы). Сделаем микротест для каждого из операторов.

Контрольный показатель

Предоставлено: по совету @ aleksandr-dubinsky и благодаря @yura за предоставление базового кода, вот тест JMH (см. это руководство по настройке):

class A {}
class B extends A {}

public class Benchmark {

    public static final Object a = new A();
    public static final Object b = new B();

    @Benchmark
    @BenchmarkMode(Mode.Throughput)
    @OutputTimeUnit(TimeUnit.MICROSECONDS)
    public boolean testInstanceOf()
    {
        return b instanceof A;
    }

    @Benchmark
    @BenchmarkMode(Mode.Throughput)
    @OutputTimeUnit(TimeUnit.MICROSECONDS)
    public boolean testIsInstance()
    {
        return A.class.isInstance(b);
    }

    @Benchmark
    @BenchmarkMode(Mode.Throughput)
    @OutputTimeUnit(TimeUnit.MICROSECONDS)
    public boolean testIsAssignableFrom()
    {
        return A.class.isAssignableFrom(b.getClass());
    }

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

        new Runner(opt).run();
    }
}

Дали следующие результаты (оценка - это количество операций в единицу времени, поэтому чем выше оценка, тем лучше):

Benchmark                       Mode   Cnt    Score   Error   Units
Benchmark.testIsInstance        thrpt  2000  373,061 ± 0,115  ops/us
Benchmark.testInstanceOf        thrpt  2000  371,047 ± 0,131  ops/us
Benchmark.testIsAssignableFrom  thrpt  2000  363,648 ± 0,289  ops/us

Предупреждение

• эталонный тест зависит от JVM и платформы. Поскольку между каждой операцией нет значительных различий, возможно, можно будет получить другой результат (и, возможно, другой порядок!) На другой версии JAVA и / или платформах, таких как Solaris, Mac или Linux.
• тест сравнивает производительность «является ли B экземпляром A», когда «B расширяет A» напрямую. Если иерархия классов более глубокая и сложная (например, B расширяет X, который расширяет Y, который расширяет Z, который расширяет A), результаты могут быть другими.
• Обычно рекомендуется писать код, сначала выбирая один из операторов (наиболее удобный), а затем профилировать свой код, чтобы проверить, есть ли узкое место в производительности. Может быть, этот оператор незначителен в контексте вашего кода, а может ...
• по отношению к предыдущему пункту instanceof в контексте вашего кода можно было бы оптимизировать легче, чем, например, isInstance ...

Чтобы дать вам пример, возьмите следующий цикл:

class A{}
class B extends A{}

A b = new B();

boolean execute(){
  return A.class.isAssignableFrom(b.getClass());
  // return A.class.isInstance(b);
  // return b instanceof A;
}

// Warmup the code
for (int i = 0; i < 100; ++i)
  execute();

// Time it
int count = 100000;
final long start = System.nanoTime();
for(int i=0; i<count; i++){
   execute();
}
final long elapsed = System.nanoTime() - start;

Благодаря JIT код в какой-то момент оптимизируется и мы получаем:

• instanceof: 6 мсек
• isInstance: 12 мс
• isAssignableFrom: 15 мс

Примечание

Первоначально в этом посте проводился собственный тест с использованием цикла for в необработанном JAVA, что дало ненадежные результаты, поскольку некоторая оптимизация, такая как Just In Time, может устранить цикл. Таким образом, в основном это было измерение того, сколько времени потребовалось JIT-компилятору для оптимизации цикла: см. Тест производительности независимо от количества итераций, чтобы получить более подробную информацию.

Связанные вопросы

• Создает ли оператор instanceof много накладных расходов? Почему?
• Как instanceof реализован внутри JAVA?
• Влияние на производительность использования instanceof в Java

Более прямой эквивалент a instanceof B -

B.class.isInstance(a)

Это работает (возвращает false), когда a тоже null.

Помимо основных различий, упомянутых выше, существует основная тонкая разница между оператором instanceof и методом isAssignableFrom в классе.

Прочтите instanceof как «это (левая часть) экземпляр этого или любого подкласса этого (правая часть)» и прочтите x.getClass().isAssignableFrom(Y.class) как «Могу я написать X x = new Y()». Другими словами, оператор instanceof проверяет, является ли левый объект тем же самым или подклассом правого класса, в то время как isAssignableFrom проверяет, можем ли мы назначить объект класса параметров (from) ссылке на класс, для которого вызывается метод.
Обратите внимание, что оба они рассматривают фактический экземпляр, а не ссылочный тип.

Рассмотрим пример трех классов A, B и C, где C расширяет B, а B расширяет A.

B b = new C();

System.out.println(b instanceof A); //is b (which is actually class C object) instance of A, yes. This will return true.  
System.out.println(b instanceof B); // is b (which is actually class C object) instance of B, yes. This will return true.  
System.out.println(b instanceof C); // is b (which is actually class C object) instance of C, yes. This will return true. If the first statement would be B b = new B(), this would have been false.
System.out.println(b.getClass().isAssignableFrom(A.class));//Can I write C c = new A(), no. So this is false.
System.out.println(b.getClass().isAssignableFrom(B.class)); //Can I write C c = new B(), no. So this is false.
System.out.println(b.getClass().isAssignableFrom(C.class)); //Can I write C c = new C(), Yes. So this is true.

Есть еще одно отличие:

нулевой экземпляр X равен false независимо от того, что такое X

null.getClass (). isAssignableFrom (X) вызовет исключение NullPointerException

Есть еще одно отличие. Если тип (класс) для тестирования является динамическим, например передается как параметр метода, то instanceof не подойдет вам.

boolean test(Class clazz) {
   return (this instanceof clazz); // clazz cannot be resolved to a type.
}

но вы можете:

boolean test(Class clazz) {
   return (clazz.isAssignableFrom(this.getClass())); // okidoki
}

Ой, я вижу, что этот ответ уже покрыт. Может быть, этот пример кому-то будет полезен.

Эта ветка дала мне некоторое представление о том, чем instanceof отличается от isAssignableFrom, поэтому я подумал, что поделюсь чем-нибудь своим.

Я обнаружил, что использование isAssignableFrom является единственным (возможно, не единственным, но, возможно, самым простым) способом спросить себя, может ли ссылка одного класса принимать экземпляры другого класса, когда для сравнения нет экземпляров ни одного класса.

Следовательно, я не нашел хорошей идеей использование оператора instanceof для сравнения назначаемости, когда все, что у меня было, были классами, если только я не задумал создать экземпляр из одного из классов; Я думал, это будет небрежно.

instanceof также нельзя использовать с примитивными или универсальными типами. Как в следующем коде:

//Define Class< T > type ... 

Object e = new Object();

if(e instanceof T) {
  // Do something.
}

Ошибка: Невозможно выполнить проверку instanceof для параметра типа T. Вместо этого используйте объект erasure Object, так как дополнительная информация об общем типе будет удалена во время выполнения.

Не компилируется из-за стирания типа с удалением ссылки времени выполнения. Однако приведенный ниже код будет компилироваться:

if( type.isAssignableFrom(e.getClass())){
  // Do something.
}

Рассмотрим следующую ситуацию. Предположим, вы хотите проверить, является ли тип A суперклассом типа obj, вы можете пойти либо

... A.class.isAssignableFrom (obj.getClass ()) ...

OR

... obj instanceof A ...

Но решение isAssignableFrom требует, чтобы здесь был виден тип obj. Если это не так (например, тип obj может относиться к частному внутреннему классу), этот параметр отключен. Однако решение instanceof всегда будет работать.

isAssignableFrom(A, B) =

if (A == B) return true
else if (B == java.lang.Object) return false
else return isAssignableFrom(A, getSuperClass(B))

Приведенный выше псевдокод является определением того, могут ли ссылки типа / класса A назначаться из ссылок типа / класса B. Это рекурсивное определение. Для кого-то это может быть полезно, для кого-то это может сбивать с толку. Я добавляю на тот случай, если кому-то это пригодится. Это просто попытка уловить мое понимание, это не официальное определение. Он используется в определенной реализации виртуальной машины Java и работает для многих примеров программ, поэтому, хотя я не могу гарантировать, что он захватывает все аспекты isAssignableFrom, он не отключен полностью.

Говоря в плане производительности "2" (с JMH):

class A{}
class B extends A{}

public class InstanceOfTest {

public static final Object a = new A();
public static final Object b = new B();

@Benchmark
@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
public boolean testInstanceOf()
{
    return b instanceof A;
}

@Benchmark
@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
public boolean testIsInstance()
{
    return A.class.isInstance(b);
}

@Benchmark
@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
public boolean testIsAssignableFrom()
{
    return A.class.isAssignableFrom(b.getClass());
}

public static void main(String[] args) throws RunnerException {
    Options opt = new OptionsBuilder()
            .include(InstanceOfTest.class.getSimpleName())
            .warmupIterations(5)
            .measurementIterations(5)
            .forks(1)
            .build();

    new Runner(opt).run();
}
}

Это дает:

Benchmark                            Mode  Cnt  Score   Error  Units
InstanceOfTest.testInstanceOf        avgt    5  1,972 ? 0,002  ns/op
InstanceOfTest.testIsAssignableFrom  avgt    5  1,991 ? 0,004  ns/op
InstanceOfTest.testIsInstance        avgt    5  1,972 ? 0,003  ns/op

Итак, мы можем сделать вывод: instanceof так же быстро, как isInstance () и isAssignableFrom () недалеко (+ 0,9% времени выполнения). Так что никакой реальной разницы, что бы вы ни выбрали

Как насчет нескольких примеров, чтобы показать это в действии ...

@Test
public void isInstanceOf() {
    Exception anEx1 = new Exception("ex");
    Exception anEx2 = new RuntimeException("ex");
    RuntimeException anEx3 = new RuntimeException("ex");

    //Base case, handles inheritance
    Assert.assertTrue(anEx1 instanceof Exception);
    Assert.assertTrue(anEx2 instanceof Exception);
    Assert.assertTrue(anEx3 instanceof Exception);

    //Other cases
    Assert.assertFalse(anEx1 instanceof RuntimeException);
    Assert.assertTrue(anEx2 instanceof RuntimeException);
    Assert.assertTrue(anEx3 instanceof RuntimeException);
}

@Test
public void isAssignableFrom() {
    Exception anEx1 = new Exception("ex");
    Exception anEx2 = new RuntimeException("ex");
    RuntimeException anEx3 = new RuntimeException("ex");

    //Correct usage = The base class goes first
    Assert.assertTrue(Exception.class.isAssignableFrom(anEx1.getClass()));
    Assert.assertTrue(Exception.class.isAssignableFrom(anEx2.getClass()));
    Assert.assertTrue(Exception.class.isAssignableFrom(anEx3.getClass()));

    //Incorrect usage = Method parameter is used in the wrong order
    Assert.assertTrue(anEx1.getClass().isAssignableFrom(Exception.class));
    Assert.assertFalse(anEx2.getClass().isAssignableFrom(Exception.class));
    Assert.assertFalse(anEx3.getClass().isAssignableFrom(Exception.class));
}

некоторые тесты, которые мы провели в нашей команде, показывают, что A.class.isAssignableFrom(B.getClass()) работает быстрее, чем B instanceof A. это может быть очень полезно, если вам нужно проверить это на большом количестве элементов.