跳转到主内容
趣航编程网 - 趣学编程,启航技术之路!

如何利用 Collections.checkedCollection 运行时类型检查实战防御泛型擦除后的非法变量注入

Collections.checkedCollection 是 Java 运行时类型安全包装器,通过在 add、addAll 等写入操作时用 getClass() 与指定 Class 精确匹配校验元素类型,防止 ClassCastException,但不检查已有元素、不支持协变、不可绕过原始引用操作。 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 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()
配合构造时遍历校验,性能更优、语义更清晰。

相关文章