Collections.checkedCollection 实战防御泛型擦除漏洞

Java 的 `Collections.checkedCollection` 是一个轻量级的运行时类型安全防护机制，专为应对泛型擦除后因非法类型插入引发的 `ClassCastException` 而设计——它不依赖编译器，而是在 `add`、`addAll` 等写入操作发生时，通过精确的 `getClass()` 匹配强制校验元素类型，实现“失败即刻暴露”的防御式编程；虽不检查已有元素、不支持继承协变、且易被原始引用绕过，但凭借零依赖、JDK 原生、低侵入等优势，特别适合对外API封装、配置驱动初始化及遗留系统渐进加固等场景，是平衡安全性与简洁性的实用利器。

Collections.checkedCollection 是 Java 提供的运行时类型安全包装器，用于在泛型擦除后仍对集合的插入操作做强类型校验，防止非法类型对象被意外添加，从而避免 ClassCastException 在后续取值时爆发。它不是编译期检查，而是在 add、addAll 等写入操作时立即抛出异常，属于“Fail-fast”式防御。

核心原理：包装 + 运行时 Class 检查

该方法返回一个动态代理（或内部包装类）实例，所有修改集合的方法（如 add、addAll、set）都会先用传入元素的 getClass() 与指定泛型类型（如 String.class）做精确匹配（不支持协变，即 Number 不能接受 Integer，除非你显式传 Number.class）。注意：它不检查已有元素，只拦截新增/修改动作。

典型使用场景与正确写法

• 对外暴露集合 API 时，防止调用方传入错误类型（如 DAO 返回 List，但希望确保只含 User）
• 配置驱动的容器初始化（如从 JSON 解析后批量 add，需兜底校验）
• 遗留代码中混用原始类型和泛型，需渐进增强健壮性

示例：

List<String> safeList = Collections.checkedList(new ArrayList<>(), String.class);
safeList.add("ok");        // ✅
safeList.add(123);         // ❌ ClassCastException: Attempt to insert class java.lang.Integer

关键限制与避坑点

• 仅对 写操作 检查，读操作（get、iterator）完全透传，不加额外开销
• 类型检查是 精确匹配，不遵循继承关系（checkedList(..., Number.class) 不接受 Integer），若需协变，应手动用 instanceof 封装逻辑
• 原始集合（如底层 ArrayList）仍可被绕过 —— 若持有原始引用并直接调用其 add，检查失效。务必只通过 checked 包装器引用操作
• 不可用于不可变集合（如 Collections.unmodifiableList 包装后的结果再 checked，会因不支持修改而立即失败）

替代方案对比：何时选它？

比起自定义装饰器或 Guava 的 ImmutableList，checkedCollection 轻量、零依赖、JDK 原生。但它不提供构建时校验或流式验证。如果需要更细粒度控制（如允许子类型、自定义转换或日志记录），建议封装自己的 SafeList；如果数据一次性构造且不再修改，优先用 ImmutableList.copyOf() 配合构造时遍历校验，性能更优、语义更清晰。

今天关于《Collections.checkedCollection 实战防御泛型擦除漏洞》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！