instanceof 仅判断类型并返回布尔值，对 null 安全；checkcast 用于强制转型校验，失败抛 ClassCastException。二者单次开销相近，但冗余使用（如先 instanceof 再强转）会触发两次检查，而模式匹配可优化为一次 checkcast。
instanceof 和 checkcast 都是 JVM 字节码中专用于引用类型检查的核心指令，但它们的语义、触发时机和运行时开销存在本质差异。理解二者在字节码层级的真实成本，对金融系统、高频事件分发等性能敏感场景尤为关键。
执行目标与语义不同，直接影响开销结构
二者虽共享底层类型查询机制（均依赖对象头中的类元数据指针），但作用完全不同：
-
instanceof：仅做“判断”，不改变栈状态；成功返回
1，失败返回0，不会抛异常；对null安全，直接返回false。 -
checkcast：是“转换前校验”，属于强制转型链的一环；若失败，必须抛出
ClassCastException；对null同样允许（JVM 规范明确null可被任意引用类型接收）。
实际字节码开销差异很小，但上下文影响巨大
单次执行时，二者在 CPU 周期和内存访问层面几乎等价——都需一次类元数据比对（比较对象的 klass 指针与目标类型的 klass 是否相等或可继承）。真正拉开性能差距的是它们所处的代码模式：
- 频繁出现的
if (obj instanceof T) { T t = (T) obj; ... }实际生成 两次类型检查：一次instanceof，一次紧跟其后的checkcast（对应强转）。这是典型冗余。 - JDK 16+ 的模式匹配写法
if (obj instanceof T t)会由编译器优化为 仅一次 checkcast（并复用结果绑定变量），跳过独立的 instanceof 指令，消除重复查表。 - 在循环内滥用
checkcast（如用 try-catch 包裹强转来代替 instanceof）会导致异常创建/抛出/捕获的完整开销，比单纯 instanceof 高 100 倍以上。
现代 JVM 的优化让二者更趋近，但不可替代
从 JDK 9 起，HotSpot 对这两条指令做了多项 JIT 优化：
- 类型预测（Type Profiling）：若某次 instanceof 在多数分支中恒为 true，JIT 会将该路径编译为直接跳转，省去运行时查表；
- 逃逸分析辅助：若对象未逃逸，JIT 可能完全内联并静态推断类型，使 instanceof 检查被彻底消除；
- checkcast 的快速路径：当目标类型是 final 类或数组类型时，JVM 使用更轻量的类 ID 比较而非完整继承链扫描。
选哪个？看你要的是“安全分支”还是“可信转型”
这不是性能二选一，而是语义定位问题：
- 需要多态分发、条件逻辑隔离 → 用 instanceof（配合模式匹配更佳）；
- 已知上游应为某类型、只容错不兜底 → 直接 checkcast（或用泛型约束避免）；
- 想绕过类型系统做动态调用 → 不要用二者硬扛，改用
MethodHandle或值类型（Java 21+）更合适。
