ClassCastException 什么时候抛出
运行时抛出 ClassCastException，说明你用 (TargetType) 强转了一个实际不是该类型的对象。JVM 在执行强制转换指令（checkcast）时发现堆中对象的实际类（或接口实现）不满足目标类型要求，就直接中断执行。
常见错误现象：
- 从
Object或父类集合里取值后盲目强转，比如(String) list.get(0)，但实际存的是Integer - 泛型擦除后丢失类型信息，比如
List rawList = new ArrayList<string>(); rawList.add(123); (String) rawList.get(0)</string> - 不同类加载器加载的同名类之间互相强转（即使类结构完全一样），也会失败
怎么安全地做类型转换
别依赖“我觉得它应该是”，要用运行时检查兜底。Java 提供了 instanceof 和 Class.isInstance()，二者语义一致，但写法和适用场景略有差异。
使用建议：
立即学习“Java免费学习笔记（深入）”；
- 普通场景优先用
if (obj instanceof String)，简洁且编译期能做 null 安全优化（Java 14+） - 反射或泛型类型动态判断时，用
String.class.isInstance(obj)，避免硬编码类字面量 - 不要写
try-catch(ClassCastException)来“试探”类型——性能差、掩盖逻辑缺陷、IDE 不会提醒你漏处理分支
示例：
Object obj = getValue();
if (obj instanceof String s) { // Java 14+ 模式匹配，s 已自动强转并非 null
System.out.println(s.length());
}
泛型擦除导致的隐性 ClassCastException
编译器把泛型当成“语法糖”，字节码里没有 List<string></string> 这种类型，只有 List。所以运行时无法阻止你往里面塞错类型，也无法验证取出来的东西是不是你要的。
关键影响：
- 原始类型（raw type）操作、反射添加元素、反序列化等场景极易触发运行时异常
- 像
ArrayList<String>被序列化再反序列化后，如果反序列化器没做类型校验，可能还原成含Integer的实例 - 第三方库返回的泛型容器（如某些 JSON 解析器），若未声明具体泛型实参，
get(0)后强转风险极高
建议：启用 -Xlint:unchecked 编译选项，把所有泛型不安全操作标出来；对不可信来源的数据，用 instanceof 再确认一次。
自定义类加载器下的 ClassCastException
两个由不同 ClassLoader 加载的相同全限定名类，在 JVM 看来是完全无关的类型。哪怕代码一模一样，A.class == B.class 为 false，相互强转必抛 ClassCastException。
典型场景：
- OSGi、Spring Boot DevTools、Tomcat 的 webapp 类加载器隔离
- 动态加载 JAR（如插件系统）时重复加载了核心类（如
org.json.JSONObject） - 测试中用
URLClassLoader加载同一份 class，但和主应用类加载器不一致
排查方法：打印出错对象的 obj.getClass().getClassLoader() 和目标类型的 Target.class.getClassLoader()，看是否为同一个实例。修复方向是统一类加载委托策略，或避免跨类加载器传递实例。
这事没法靠加 instanceof 解决——因为类型根本不在同一个命名空间里。
