防御性拷贝：防止外部修改的技巧与方法

本文深入剖析了Java中因直接返回集合引用而导致内部状态被外部篡改的经典安全陷阱——看似私有且final的集合字段，实则因引用暴露而形同虚设；文章直击问题本质：final只锁定引用不可变，不阻止内容修改，而“请勿修改”的文档约定在真实生产环境中毫无约束力；进而给出切实可行的防御方案：根据性能与语义需求，选择返回不可变视图（如Collections.unmodifiableList）或独立副本（如new ArrayList(items)），从根本上切断外部对内部数据结构的非法干预，让封装真正落地、让代码坚不可摧。

为什么 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学习网公众号也会发布文章相关知识，快来关注吧！