必须用 instanceof 而不是直接强转，当不确定 Object 引用实际子类型时（如 Map.get()、反序列化、回调参数），否则会抛 ClassCastException；需先判断再转型以确保安全。
什么时候必须用 instanceof 而不是直接强转
当你拿到一个 Object 类型（或父类/接口）引用，但不确定它实际是不是某个子类型时，直接强转会抛 ClassCastException。比如从 Map.get() 拿到值、反序列化泛型擦除后的对象、处理回调传入的通用参数。
安全做法是先用 instanceof 判断再转型：
Object obj = getValue();
if (obj instanceof String) {
String s = (String) obj; // 此时强转 100% 安全
System.out.println(s.length());
}
注意：JDK 14+ 支持模式匹配（if (obj instanceof String s)），但老版本仍需显式转型。
instanceof 对 null 的行为和常见误判
instanceof 遇到 null 永远返回 false，不会抛异常——这是它比 getClass().equals() 更安全的地方。
立即学习“Java免费学习笔记（深入）”；
容易踩的坑：
- 误以为
null instanceof SomeClass是true（实际是false） - 在判断接口实现时写错类名，比如
list instanceof ArrayList—— 若实际是LinkedList就失败，应优先判断接口：list instanceof List - 对数组类型判断写法特殊：
arr instanceof int[]合法，但arr instanceof Integer[]和arr instanceof Object[]行为不同，后者可能意外为true
替代方案对比：为什么不用 getClass() == Xxx.class
obj.getClass() == String.class 只能匹配精确类型，不接受子类；而 instanceof 支持继承关系判断（如 StringBuilder instanceof CharSequence 返回 true）。
适用场景差异：
- 需要“是否为该类型或其子类” → 用
instanceof - 需要“是否恰好是这个类，不能是子类” → 用
obj.getClass() == Xxx.class - 判断泛型类型信息（如
List）→instanceof无能为力（类型擦除），得靠反射 +ParameterizedType
性能影响和 JIT 优化的实际情况
现代 JVM（HotSpot）对 instanceof 做了深度优化，尤其是当类型分支稳定时，常被内联为几条 CPU 指令，开销极小。别为了“避免 instanceof”而强行用字符串比较类名或维护类型映射表。
但要注意：
- 在高频循环里做多次不同类型的
instanceof判断（比如解析混合对象列表），可能触发类型检查缓存未命中，此时可考虑用Visitor模式或枚举分发 - Android Dalvik/ART 上早期版本优化较弱，不过 Android 8.0+ 已基本对齐 HotSpot 表现
- 永远不要用
instanceof替代多态设计——如果发现自己写了十几个if (x instanceof A) {...} else if (x instanceof B) {...}，说明该重构为方法重载或策略模式了
真正难处理的是跨模块、非继承体系的类型适配，这时候 instanceof 只是起点，后面往往要接工厂或转换器。
