instanceof 优化关键在于避免滥用而非提速，应优先用多态、预处理类型标识、模式匹配（java 16+）和 sealed class（java 17+），禁用跨包装类误判，杜绝循环中高频调用。
instanceof 本身开销很小，但在不当使用时会暴露设计缺陷或引发可观测的性能损耗。优化重点不在“怎么让 instanceof 更快”，而在于“什么时候不该用它”以及“如何用得更合理”。
避免在循环中高频调用
频繁判断类型是性能隐患的典型场景。比如遍历大型对象数组并逐个用 instanceof 分类，JVM 需对每个对象查类继承链，尤其当继承层级深或存在接口实现时，开销叠加明显。
- 用多态方法替代：把类型分支逻辑下沉到子类重写的虚方法中，一次 dispatch 解决，比 N 次 instanceof + if-else 更高效
- 若必须分类统计，可预处理：在对象创建时记录类型标识（如 enum 或 int 类型码），后续用 switch 或查表代替运行时类型检查
- 注意 JIT 编译器的限制：即使单次 instanceof 很快，JIT 对循环内多次调用的优化能力有限，容易退化为解释执行
优先采用模式匹配语法（Java 16+）
传统写法需要两次类型提及（obj instanceof String + (String) obj），不仅冗余，还可能因手动强转引入 ClassCastException。模式匹配把类型检查和变量绑定合二为一。
- 语法简洁：
if (obj instanceof String s) { ... }，s 在块内自动具备 String 类型，无需再 cast - 空安全：obj 为 null 时条件直接为 false，s 不会被初始化，杜绝 NullPointerException
- 编译器保障：绑定变量仅在类型匹配成功时生效，类型安全性由编译期验证，不增加运行时负担
警惕跨包装类的误用
instanceof 对基本类型完全无效，对包装类也只认继承关系。比如 Long l = 100L; l instanceof Integer 编译失败——不是性能问题，而是语义错误。
- 数值类型判断应走值比较或工具类（如
Objects.equals(a, b)），而非 instanceof - 若需统一处理数字，定义 Number 接口的抽象操作，利用多态分发，而不是靠 instanceof 区分 Long/Integer/Double
- JVM 层面：基本类型无对象头、无类型元数据，instanceof 指令字节码（
instanceof）只作用于引用类型，这点无法绕过
用静态结构替代运行时检查
当类型集合固定且已知（如解析器中的 AST 节点类型），可考虑用 sealed class + switch 模式匹配（Java 17+），或枚举+策略映射表。
- sealed class 限定所有子类，编译器可生成更优的跳转表，比 instanceof 链式判断更快更安全
- 策略表方式：Map
, Handler> 预注册处理器，但要注意 Class 对象作为 key 的哈希开销，适合类型数少、调用频次高的场景 - 模板/泛型方案（C++ 或 Java 泛型擦除前）：把类型决策移到编译期，彻底消除运行时类型检查
