第5章　ClassCastException：类型擦除与桥接方法引发的陷阱

5.1 checkcast 指令：显式插入的类型检查

和 NPE 不同，ClassCastException 确实对应一条 javac 主动插入的显式字节码指令：checkcast 。例如 (Integer) obj 这样的强制转型语句，编译后就是一条 checkcast #类型 指令：栈顶引用如果不是目标类型（或其子类型），JVM 抛出 CCE；如果是，则原样保留在栈上（checkcast 不消费栈，只做检查）。

5.2 泛型擦除导致的"隐藏 checkcast"：实测验证

Java 泛型是编译期擦除 实现的------运行时字节码里根本没有 List<Integer> 这种类型信息，只有裸的 List。为了让"泛型看起来类型安全"，javac 会在调用点 自动插入 checkcast，而不是在 List 内部。用下面这段刻意绕过泛型检查的代码验证：

java 复制代码

List list = new ArrayList();      // 使用 raw type，绕过编译期泛型检查
list.add("hello");                 // 编译器允许，只给 unchecked warning
List<Integer> intList = list;      // 同样只是 warning，不是 error
Integer x = intList.get(0);        // 运行时才会出问题

实际反汇编（JDK 21）在 get(0) 调用点：

vbnet 复制代码

19: invokeinterface #18,  2   // InterfaceMethod List.get:(I)Ljava/lang/Object;
22: checkcast     #22          // class java/lang/Integer   ← javac 自动插入

List.get() 接口方法签名擦除后返回的是 Object，javac 在每一个调用 intList.get(0) 的地方 都自动补上一条 checkcast Integer，让调用方看起来像是"直接拿到了 Integer"。当 list 里实际存的是 String 时，运行报错：

vbnet 复制代码

Exception in thread "main" java.lang.ClassCastException:
    class java.lang.String cannot be cast to class java.lang.Integer
    (java.lang.String and java.lang.Integer are in module java.base of loader 'bootstrap')

这揭示了一个重要认知 ：泛型的"类型安全"完全是编译期的假象 ，一旦通过 raw type、反射、或不安全的强转绕过编译器检查，运行时该出错还是会出错------而且报错的位置往往不是"真正存入错误类型"的那一行，而是"取出来强转"的那一行，这也是排查此类 CCE 时容易走弯路的原因：堆栈指向的行号是消费方，而不是生产方，需要人工回溯是谁把不该出现的类型放进了这个集合。

5.3 桥接方法（Bridge Method）：泛型接口实现导致的第二类隐藏转型

当一个类实现带泛型参数的接口（如 Comparator<String>）时，javac 会额外生成一个桥接方法 ，签名是擦除后的原始类型，内部调用真正的实现方法。实测反汇编一个 Comparator<String> 实现类：

vbnet 复制代码

public int compare(java.lang.String, java.lang.String);   // 用户实际写的方法
  ...（真实逻辑）

public int compare(java.lang.Object, java.lang.Object);   // javac 自动生成的桥接方法
  Code:
     0: aload_0
     1: aload_1
     2: checkcast     #8    // class java/lang/String   ← 桥接方法里插入的类型检查
     5: aload_2
     6: checkcast     #8    // class java/lang/String
     9: invokevirtual #13   // 调用真正的 compare(String, String)
    12: ireturn

这就是为什么下面这段代码会抛 CCE：

java 复制代码

Comparator raw = new MyComparator();      // 用 raw type 接收
raw.compare(new Object(), "x");           // 编译能过（raw type 参数是 Object）
// 运行时：桥接方法内部的 checkcast 发现 new Object() 不是 String，抛 CCE

工程含义 ：这也是为什么绝大多数 IDE 和静态检查工具（包括 SonarQube 的相关规则）都会把"使用 raw type"标记为警告级别问题------它不只是风格问题，而是实实在在地关闭了编译期类型检查，把本该在编译期发现的错误推迟到了运行时，且报错堆栈还会指向一个用户代码里根本看不到的、编译器自动生成的桥接方法（javap 里能看到，但源码里没有对应行）。

5.4 跨 ClassLoader 场景的"同名不同类"CCE

（本节承接 Part 1 中提及的多 ClassLoader 场景，此处专门展开）当同一个类被两个不同的 ClassLoader 分别加载，JVM 判定类型相同与否的依据是 (全限定类名, 定义该类的 ClassLoader) 这个二元组，而不仅仅是类名。哪怕字节码内容一模一样，只要加载它们的 ClassLoader 实例不同，就是两个不同的 Class 对象，互相转型必然抛 CCE，异常信息里会明确带上 loader 信息：

vbnet 复制代码

class com.example.User cannot be cast to class com.example.User
(com.example.User is in unnamed module of loader 'app';
 com.example.User is in unnamed module of loader 'plugin')

排查这类问题的关键信号就是异常信息里出现了两个 loader 名称，此时排查方向不是"类哪里写错了"，而是"这个类为什么被加载了两次"------常见于 Web 容器多应用隔离、模块化插件系统、以及某些"热部署"框架用自定义 ClassLoader 替换类实现的场景。

第5章 ClassCastException：类型擦除与桥接方法引发的陷阱