checkedcollection 是 collections.checkedcollection 等静态工厂方法返回的运行时类型检查包装类，仅在 add/addall/set 等写操作时用 instanceof 校验元素类型，不防 null、反射、序列化绕过，不改变底层行为，抛 classcastexception 且无精准调用栈，性能有开销，jdk 自身极少使用，替代方案应优先选用不可变容器或封装控制。
CheckedCollection 是什么，为什么它几乎没人用
它不是编译期类型检查工具，也不是泛型擦除的补救方案；它是 Collections.checkedCollection 等一系列静态工厂方法返回的包装类，在每次 add、addAll、set 等写操作时，用 instanceof 检查元素类型——仅此而已。
这意味着：它只拦得住运行时传进来的非法对象，拦不住 null（除非你显式检查）、拦不住泛型擦除后“看起来合法”的误用，更拦不住反射或序列化绕过。
- 它不改变底层集合行为，只是加了一层运行时类型断言
- 所有 checked 方法（如
checkedList、checkedSet）都要求传入原始类型 Class 对象，比如String.class，不能传List<string>.class</string>（这语法本身就不合法） - 一旦触发类型不匹配，抛出
ClassCastException，但异常栈里不会显示是哪个 add 调用导致的——因为检查发生在包装器内部
CheckedList.add() 为什么会突然抛 ClassCastException
这不是 bug，是设计使然：只要往 Collections.checkedList(new ArrayList(), String.class) 里塞一个 Integer，就会在 add 调用时立刻失败。
- 错误现象：
java.lang.ClassCastException: java.lang.Integer cannot be cast to java.lang.String - 容易忽略的点：子类实例可以过检（比如
StringBuilder无法通过String.class检查），但接口实现类不行（ArrayList不是List.class的实例） - 如果你用的是自定义类，且重写了
equals或用了 Lombok @Data，注意instanceof不依赖 equals，只看实际运行时类 - 别指望它能捕获泛型误用：写
checkedList(new ArrayList(), Number.class)后往里加String，照样过检——因为String不是Number的子类，但检查逻辑是“元素 instanceof 声明类型”，所以这里反而会失败
CheckedCollection 和 Collections.unmodifiableXXX 的根本区别
一个是“写时校验”，一个是“写即报错”。它们解决的问题完全不同，混用反而坏事。
立即学习“Java免费学习笔记（深入）”；
-
Collections.unmodifiableList包装后任何修改操作都抛UnsupportedOperationException，和类型无关 -
Collections.checkedList允许修改，但强制类型匹配；它甚至可以和 unmodifiable 组合使用，比如先 checked 再 unmodifiable，但顺序不能反——否则 unchecked 的底层集合可能被绕过 - 性能上：checked 版本每次 add 都有一次
instanceof判断，对高频写场景有可测开销；unmodifiable 只是代理转发，基本无额外成本 - 兼容性：checked 类型在 JDK 1.5+ 都存在，但它的 API 在 Java 9+ 没有任何增强，也没被 Record、Sealed Class 等新特性适配
替代 CheckedCollection 的更可靠做法
真要强类型约束，靠运行时包装不如从源头控制。JDK 自己都不怎么用它，是有原因的。
- 优先用不可变容器：比如
List.of("a", "b")（Java 9+）或 Guava 的ImmutableList，创建即定型，类型在构造时就由编译器保证 - 用封装类隐藏集合字段：把
private List<string> tags</string>改成私有 + 显式 add 方法，在方法体内做类型判断或断言，比通用包装器更容易定位问题 - 测试阶段用
assert或单元测试覆盖非法输入，比生产环境抛ClassCastException更早暴露问题 - 如果必须动态类型检查，考虑用
Objects.requireNonNull+ 手动instanceof，至少你能控制异常消息和位置
它存在的意义，其实是提醒你：运行时类型检查是脆弱的，而真正可靠的类型安全，得靠编译器、不可变性、以及不让非法状态有机会出现的设计。
