collections.checkedcollection() 提供运行时类型安全包装，仅对写操作检查元素类型，不验证已有元素或读操作返回值；需传入非空原始集合和具体类型class，适用于api边界防护等场景。
Collections.checkedCollection() 是 Java 提供的一种运行时类型安全包装工具，它能在向集合添加元素时检查类型是否匹配，避免 ClassCastException 在后续遍历时才暴露。但它**只对写操作（如 add、addAll）做检查，不检查已有元素的类型，也不检查读操作返回值的强制转型**。
基本用法：包装后获得类型安全的视图
你需要传入原始集合和期望的元素类型（Class<e></e>），方法返回一个动态代理包装后的集合：
- 原始集合可以是任意实现类（
ArrayList、HashSet等），但必须非空或已初始化； - 类型参数
E必须是具体类（不能是泛型变量或通配符），例如String.class，不能写T.class； - 包装后所有修改操作都会在执行前校验元素是否可赋值给该类型，不满足则抛出
ClassCastException。
示例：
List<object> rawList = new ArrayList();
List<string> safeList = Collections.checkedList(rawList, String.class);
safeList.add("hello"); // ✅ 通过
safeList.add(123); // ❌ 运行时报 ClassCastException
</string></object>
注意：已有元素不会被重新验证
如果原始集合中已存在非法类型元素，checkedCollection() 不会主动扫描并报错——它只拦截新增/替换动作。这意味着：
- 构造前请确保原始集合内容合法，否则后续读取时仍可能触发异常（尤其在强转为泛型类型使用时）；
- 例如：用
new ArrayList(Arrays.asList("a", 42))包装成checkedList(..., String.class)，构造成功，但调用get(1)返回Integer，若代码写成String s = list.get(1)，编译通过，运行时报错； - 所以建议只对全新或已清洗过的集合进行包装。
适用场景与局限性
这个机制适用于需要在遗留代码（如接收 List<object></object> 参数）中增强类型安全性，且无法修改底层存储结构的情况：
- 适合短期过渡、测试辅助、API 边界防护；
- 不适合高性能高频写入场景（每次 add 都有反射类型检查开销）；
- 不解决泛型擦除问题，编译期仍无保障，仅补充运行时防御；
- 对
Iterator.remove()、clear()等不涉及新元素的操作无影响； - 不支持并发安全，如需线程安全，请额外套用
Collections.synchronizedXxx()（注意：应先 checked 再 synchronized）。
其他 checked 方法家族
Collections 类还提供对应变体，语义一致，仅适配不同接口：
-
checkedList()→List -
checkedSet()→Set -
checkedSortedSet()→SortedSet -
checkedNavigableSet()→NavigableSet -
checkedMap()→Map<k></k>（同时检查 key 和 value 类型）
选择与你实际使用的集合接口匹配的方法即可。
