Collections.checkedCollection 解决泛型类型污染问题，通过在 add 等修改操作时立即执行 instanceof 类型检查，将 ClassCastException 提前至插入时刻而非取值时；它仅校验运行时类类型，不检查通配符、反射绕过、原始类型创建或序列化等场景。
Collections.checkedCollection 是 Java 集合框架中用于在运行时增强泛型安全性的工具方法，它返回一个包装后的集合视图，在每次添加元素时执行类型检查，从而在发生类型污染（type pollution）时立即抛出 ClassCastException，而非等到取值时才暴露问题。
它解决什么问题？
Java 泛型是编译期擦除的，原始类型（raw type）或反射操作可能绕过编译检查，向泛型集合中插入非法类型对象，造成“类型污染”。例如：
List<String> safeList = new ArrayList<>(); List rawList = safeList; // 警告但可通过编译 rawList.add(123); // 运行时不报错，污染发生 String s = safeList.get(0); // 此处才抛 ClassCastException
这种延迟失败难以定位。checkedCollection 就是为了把失败点前移到插入时刻。
怎么用？关键行为要清楚
调用方式简单，但需注意其约束和局限：
立即学习“Java免费学习笔记（深入）”；
- 只对
add、addAll、set（对 List）等修改操作做检查；查询操作（如get、iterator()）不额外校验 - 返回的是动态代理包装类，不是新集合，底层仍指向原集合；因此原集合若被绕过包装直接操作（如用 raw type），污染仍会发生
- 仅检查运行时类类型，不支持泛型通配符细化（如
List<? extends Number>无法直接 checked） - 对数组、Map 的 key/value 等需用对应方法：如
checkedList、checkedMap、checkedSet
典型使用场景与建议
适用于需要对外暴露集合引用，又必须防止非法写入的接口边界：
- 作为 public API 返回值（如 getter 方法），避免调用方通过 raw type 注入错误类型
- 在模块间传递集合时，配合封装类一起使用（例如内部用普通 ArrayList，getter 返回 checkedList 包装）
- 不推荐用于高频写入的热路径——每次 add 都有一次
instanceof检查，有轻微开销 - 不能替代编译期检查，而是补充；应优先靠代码规范和 IDE 提示规避 raw type 使用
它挡不住哪些情况？
checkedCollection 并非万能，以下情形它无能为力：
- 通过反射调用
add方法并绕过包装实例（如获取到内部 delegate 后直接操作） - 集合本身是原始类型创建的（如
new ArrayList()），再用checkedList(..., String.class)包装——此时已有污染风险，包装只能拦住后续插入 - 泛型类型参数是类型变量（如
<T> List<T> wrap(T t)），运行时无法确定 T 的具体类，checked 方法要求传入确切Class对象 - 序列化/反序列化过程中的类型绕过（如用 JSON 库将 int 写入 String 列表字段）
