怎么利用 Collections.unmodifiableSet() 防止外部代码修改核心配置集合

怎么利用 Collections.unmodifiableSet() 防止外部代码修改核心配置集合

先明确一个关键事实：Collections.unmodifiableSet() 提供的仅仅是运行时修改拦截，它无法阻断原始引用的泄露。换句话说，如果原始的 Set 还被其他变量持有并修改，那么所有基于它创建的不可变视图，都会同步读到“脏数据”。真正的防护，往往需要先进行防御性拷贝（比如使用 new HashSet() 或 Set.copyOf()），再进行封装。

为什么 Collections.unmodifiableSet() 不能真正“防住”修改

问题根源在于，这个方法只是在调用修改操作（如 add、remove）时抛出 UnsupportedOperationException，它并没有切断与原始集合的关联。想象一下，原始集合的引用如果还在别处“流通”，外部代码完全可以直接修改那个源头——这时，所有依赖它的不可变视图就瞬间失效了。

• 因此，首要原则是：在创建不可变视图之前，必须确保原始集合已经“退役”，不再被任何其他代码写入（这包括内部类、静态字段、缓存等隐蔽角落）。
• 一个常见的陷阱是：将原始集合赋值给 public static 字段，或者在构造器中返回其引用。切记，Collections.unmodifiableSet() 返回的是一个装饰器（wrapper），底层依然持有原始 Set 的引用，这并非深拷贝。

正确封装配置 Set 的三步操作

核心逻辑可以概括为：“截断可变引用、提供安全访问、避免意外逃逸”。典型的错误做法，就是只套上一层 unmodifiable 包装便以为高枕无忧。

• 第一步，使用 new HashSet(original) 或 Set.copyOf()（Ja va 10+）进行一次防御性拷贝，再将拷贝后的集合传给 Collections.unmodifiableSet()。
• 第二步，将得到的不可变视图存入 private final 字段，并在 getter 方法中直接返回该字段（避免每次调用都重新包装）。
• 第三步，如果配置需要动态更新，切勿复用旧的集合对象；正确的做法是重建一个全新的集合，并重新进行包装，以此杜绝旧视图与新数据混杂的风险。

private final Set allowedHosts = Collections.unmodifiableSet(
    Set.copyOf(Arrays.asList("api.example.com", "cdn.example.com")));

对比 Set.copyOf() 和 Collections.unmodifiableSet() 的实际差异

Ja va 10 引入的 Set.copyOf() 提供了一个更安全的选项：它一次性完成了防御性拷贝并返回一个不可修改的视图，同时对 null 元素的检查也更为严格。

• Collections.unmodifiableSet(s)：仅要求参数 s 非 null，但不检查集合内元素是否为 null；并且，一旦 s 后续被修改，视图立即失效。
• Set.copyOf(s)：要求参数 s 非 null，且集合内不能包含 null 元素；它返回的是 JVM 内部实现的 ImmutableSet，完全不依赖原始引用。
• 在性能层面，对于小集合，Set.copyOf() 通常更快（因为它避免了额外的包装层），并且其序列化行为也更具可预测性。

常见误用导致的静默失败场景

最危险的情况莫过于“看似不可变，实则可变”。例如，在 Spring Bean 的初始化过程中，不经意间暴露了未受保护的集合。

• 在 @Configuration 类中，使用 @Bean 方法返回 Collections.unmodifiableSet(...)，但方法体内却反复新建同一个可变 Set —— 这会导致每次返回的其实是不同实例，无法保证配置的一致性。
• 将不可变 Set 存入 ConcurrentHashMap，却在使用 computeIfAbsent 等方法时直接返回了原始的可变集合 —— 外部获取到的就是一个可操作的引用。
• 在日志打印时调用集合的 toString() 方法，而原始集合恰好是 LinkedHashSet 且正被并发修改 —— 这会抛出 ConcurrentModificationException，但错误堆栈可能完全指向日志代码，而非真正的配置源头。

说到底，真正可靠的防护，从来不是依赖一层薄薄的包装。关键在于严格控制集合生命周期的起点与终点。一旦允许原始引用流出其应有的作用域，那么再厚的不可变外壳，也终将形同虚设。