我可以想象一些情况，例如，你有一个库的一些对象，你不能扩展（或者这样做会很不方便），可能与你的一些对象混合在一起，所有的对象都有相同的基类，在一个集合中。
我想在这种情况下，使用instanceof来区分这些对象上的一些处理可能是有用的。
idem在一些遗留代码的维护中，你不能仅仅为了添加一个新的小特性或一些bug修复而在很多旧类中注入一些新的行为。。。

它可以很好地作为一个健全的检查前铸造；除了检查对象的类型是否正确，它还检查对象是否为null。

if (o instanceof MyThing) {
    ((MyThing) o).doSomething(); // This is now guaranteed to work.
} else {
    // Do something else, but don't crash onto ClassCast- or NullPointerException.
}

我认为当你需要知道物体的类型时， instanceof 是最好的选择。
不好的做法是 instanceof s、 一个接一个，并根据它们调用对象的不同方法（当然是铸造）。这可能反映出层次结构需要重新思考，也可能需要重构。

如果是创作工厂呢？例如

public static Cage createCage(Animal animal) {
  if (animal instanceof Dog)
    return new DogHouse();
  else if (animal instanceof Lion)
    return new SteelCage();
  else if (animal instanceof Chicken)
    return new ChickenWiredCage();
  else if (animal instanceof AlienPreditor)
    return new ForceFieldCage();
  ...
  else
    return new GenericCage();
}

当您在纯oo模型中时 instanceof 绝对是一种代码气味。
但是，如果您没有使用100%的oo模型，或者需要从外部向其中注入内容，那么instanceof或等效的( isXXX() , getType() ，…）可以有它的用途。
一般的“规则”是尽可能避免它，特别是当您控制类型层次结构并且可以使用子类型多态性时。其目的不是询问对象是什么类型的，并对其进行处理，而是通过访问者（本质上是双重多态性）直接或间接地要求对象执行某些操作。

它肯定在一个股票执行中占有一席之地 equals . 例如

public boolean equals ( Object o )
{
  if ( this == o )
  {
     return true;
  }

  if ( ! (o instanceof MyClass) )
  {
    return false;
  }

  // Compare fields
  ...
}

关于instanceof，有一件很好的事情要知道，它的lhs可以是 null 在这种情况下，表达式的计算结果为 false .

我同意它可能有股难闻的味道。很多情况下，特别是在一个锁在一起，如果块，气味不好。
有时它会以你意想不到的方式表现。。。我曾经发生过一件事：

Class B extends A
Class C extends A

B b = new B();
C c = new C();

b instanceof B -> true
b instanceof C -> true
c instanceof C -> true
c instanceof B -> true

（在我的例子中，这是由于hibernate生成代理对象。。。。但在instanceof上执行代码dpending是有风险的）