checkcast指令检查对象实际运行时类是否为目标类型的子类或实现类，对null直接放行；其性能瓶颈不在指令本身，而在继承链遍历开销及暴露的设计缺陷——应优先用编译期多态替代运行时类型判断。
checkcast 指令到底在检查什么
它不检查「变量声明类型」，只检查「对象实际运行时类」是否是目标类型的子类或实现类。比如 Object obj = new ArrayList<string>()</string>，执行 (List) obj 时，JVM 看的是 ArrayList 是否继承或实现了 List——是的，所以通过；但若 obj 实际是 File 实例，File 和 List 无继承关系，checkcast 就抛 ClassCastException。
注意：checkcast 对 null 值直接放行，不校验也不抛异常——这是 JVM 规范明确规定的，所以 (String) null 不会崩，只是后续用到时可能 NPE。
为什么 instanceof 和 checkcast 成本几乎一样
因为它们底层都依赖同一套运行时类型查询机制：JVM 需要读取对象头中的 klass pointer，再遍历类的继承链（包括接口实现表）确认兼容性。这个过程不是 O(1)，而是 O(D)，D 是类继承深度。
常见误解是「instanceof 快、checkcast 慢」，其实编译器常把二者合并优化：比如 if (obj instanceof String) { s = (String) obj; }，JIT 可能只做一次类型查表，避免重复遍历。
真正影响性能的不是指令本身，而是以下情况：
- 大量临时对象频繁触发 GC，导致 klass pointer 缓存失效，每次都要重新加载类元数据
- 使用动态代理（如 Spring AOP）后，实际类变成
com.sun.proxy.$ProxyXX，继承链变长，checkcast查找路径拉长 - 泛型擦除 + 强转组合（如
(List<string>) list</string>），虽然编译通过，但checkcast目标仍是原始类型List.class，无法校验泛型参数，徒增无效检查
反编译看 checkcast 的真实位置
写一段典型向下转型代码：
Object obj = getSomeObject();
if (obj instanceof String) {
String s = (String) obj;
System.out.println(s.length());
}
用 javap -c 反编译后，你会看到两处 checkcast：
- 一处在
instanceof编译后的字节码里（其实是checkcast+ifnull组合逻辑） - 另一处在
(String) obj这行，对应一条独立的checkcast java/lang/String指令
但如果用 JDK 14+ 的模式匹配写法：if (obj instanceof String s)，反编译会发现只剩一个 checkcast，且后续对 s 的使用不再重复校验——这是明确的 JIT 友好写法。
checkcast 的成本在哪儿容易被忽略
它本身不慢，但它的存在暴露了设计断层：每次出现 checkcast，基本意味着你在用「运行时类型分支」替代「编译期多态」。比如反复对集合元素做 instanceof + 强转，本质是在模拟 switch on type，而 Java 的虚方法调用（invokevirtual）在现代 JVM 上早已高度优化，内联率极高。
更隐蔽的代价是内存布局干扰：强转本身不改对象，但为了支持快速类型查询，JVM 必须为每个类维护完整的继承关系快照，这部分元数据会常驻 Metaspace，且无法被常规 GC 回收。
所以别只盯着 checkcast 指令耗多少纳秒，先问一句：这段转换，是不是本该由接口定义行为、由子类各自实现？
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
