集合防御性拷贝是什么及如何防范

文章小白一枚，正在不断学习积累知识，现将学习到的知识记录一下，也是将我的所得分享给大家！而今天这篇文章《集合防御性拷贝是什么及防范方法》带大家来了解一下##content_title##，希望对大家的知识积累有所帮助，从而弥补自己的不足，助力实战开发！

getItems() 返回原始引用导致内部状态被篡改，因Java集合默认不拷贝、final仅锁引用不锁内容；安全做法是返回不可变视图或独立副本。

为什么 getItems() 返回的 List 被调用方一改，内部状态就乱了

因为返回的是原始引用，不是副本。Java 中集合类（如 ArrayList、HashSet）默认不自动拷贝，return items; 就是把堆里那个对象的地址直接交出去了。

常见错误现象：myObj.getItems().add("hacked"); 后，myObj 内部的 items 真的多了一项；或者外部调用 clear() 导致业务逻辑崩掉。

• 只要方法签名返回的是可变集合类型（List、Set、Map），且没做隔离，就存在风险
• 即使字段声明为 private final List items;，final 只锁住引用，不锁住内容
• 别依赖文档说“请勿修改”，生产环境没人看文档，只看 IDE 自动补全出来的 add()

怎么写一个真正安全的 getItems()

核心原则：返回不可变视图或独立副本。选哪种取决于性能和语义需求。

使用场景：如果集合不大（

• 返回新副本（防御性拷贝）：return new ArrayList<>(this.items); —— 安全，但每次调用都新建对象，注意 GC 压力
• 返回不可变视图（JDK 10+）：return List.copyOf(this.items); —— 零拷贝，但返回的是 ImmutableList，任何修改操作会抛 UnsupportedOperationException
• 旧 JDK（如 8）可用 Collections.unmodifiableList(this.items) —— 注意：它只是加了运行时检查，底层仍是原集合，若原集合被其他路径修改，视图会同步反映变化（不彻底安全）

addAll() 或构造器传入集合时，要不要也拷贝

要。防御性拷贝不是只防 getter，所有“接收外部集合并存为成员”的入口都得拦住。

参数差异：public void setItems(List input) { this.items = new ArrayList<>(input); } 和 this.items = input; 看似只差一行，实则安全等级天壤之别。

• 构造器里直接 this.items = items; 是高危写法，外部传进来的 ArrayList 一旦被缓存或复用，等于开了后门
• 用 addAll() 批量添加？先确认传入的是副本还是原始引用 —— 如果来源是 request.getParams() 这种框架返回的集合，大概率也是裸引用
• Spring MVC 的 @RequestBody 解析出的 List 默认可变，别直接塞进领域对象字段

泛型擦除会让 unmodifiableList 失效吗

不会。泛型只在编译期起作用，Collections.unmodifiableList 的运行时行为与泛型无关，它拦截的是 add()、remove() 等方法调用，不是类型检查。

容易踩的坑：有人以为用 List 声明 + unmodifiableList 就万无一失，结果在别的地方写了 ((ArrayList) items).add(123); —— 强转绕过了泛型，也绕过了不可变包装的代理层（因为 unmodifiableList 返回的是装饰器对象，强转成原始实现类就脱钩了）。

• 永远不要对不可变包装结果做强制类型转换
• 如果真需要运行时类型安全，配合 instanceof 检查 + 明确拒绝非预期类型，而不是靠泛型幻想
• 最稳的路：统一用副本（new ArrayList<>(input)），哪怕多占点内存，也比追查“谁偷偷改了集合”强

真正的难点不在怎么写那行 new ArrayList，而在于意识到：每个接收或返回集合的地方，都是潜在的共享内存区域。没人会故意破坏，但并发、复用、误用，三者叠加起来，比空指针还难复现。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于文章的相关知识，也可关注golang学习网公众号。