不可变集合防止数据篡改方法

Java 9 引入的 List.of() 和 Map.of() 是创建轻量级不可变集合的利器，能有效防止业务数据被意外增删改，提升线程安全性与代码可维护性；但它们并非“万能锁”——仅保障集合结构不可变，不阻止元素内部状态变更，且受限于 null 不支持、参数数量上限、特定方法（如 subList、sort）不可用等现实约束，适用于配置项、状态码映射等只读场景；真正安全需双管齐下：容器层用不可变集合明确契约，元素层确保对象本身不可变或做防御性拷贝，否则看似坚固的防线可能在不经意间被绕过。

为什么 List.of() 和 Map.of() 创建的集合不能 add/remove

因为它们返回的是 JVM 内置的不可变实现类（如 ListN、ImmutableCollections.MapN），底层直接抛出 UnsupportedOperationException，不是靠封装或代理拦截。调用 add()、put()、clear() 等任何修改方法都会立即失败，而不是静默忽略或延迟报错。

常见错误现象：在 service 层返回了 List.of(user1, user2)，但 controller 层试图 list.add(newUser) —— 运行时直接炸，堆栈里能看到 java.lang.UnsupportedOperationException。

• 只适用于数据确定后就不再变更的场景，比如配置项列表、HTTP 响应码映射表、枚举别名字典
• 不支持 null 元素：List.of(null) 和 Map.of("k", null) 都会抛 NullPointerException
• 元素个数上限：List.of() 最多支持 10 个参数，超了得用 List.ofArray(new String[]{...})（Java 14+）或退回到 Collections.unmodifiableList()

Map.of() 的键冲突和重复值怎么处理

Map.of("a", 1, "b", 2, "a", 3) 会在编译期报错（Java 14+），不是运行时报错；而 Map.ofEntries() 在运行时检测到重复 key 才抛 IllegalArgumentException，提示 “duplicate key: a”。这点很关键——它让问题暴露得更早。

使用场景上，适合定义固定结构的映射关系，比如：

Map<String, Integer> statusMapping = Map.of(
    "CREATED", 100,
    "PROCESSING", 200,
    "COMPLETED", 300
);

• 如果业务需要允许重复 key（比如多值映射），别硬套 Map.of()，改用 Map.ofEntries(Map.entry("k", v1), Map.entry("k", v2)) 不行——它仍不允许重复 key；此时应选 ImmutableMultimap（Guava）或自己封装
• Map.ofEntries() 是唯一能构造含空格/特殊字符 key 的方式（比如 Map.entry("user-id", 123)），Map.of() 的参数必须是合法标识符形式

不可变集合真的“绝对安全”吗

不。它们防的是集合结构被修改，但不防元素对象自身被改。比如 List.of(new User("Alice"))，虽然 list 不能 add/remove，但 list.get(0).setName("Bob") 依然生效——前提是 User 是可变类。

所以真正防篡改要分两层：

• 集合容器层：用 List.of() / Map.of() 封住增删改结构操作
• 元素内容层：确保元素类型本身不可变（如用 record、final 字段 + 无 setter 的 POJO，或手动 deep copy）
• 如果元素是数组或 java.util.Date 这种典型可变类型，即使放进 List.of()，外部仍可通过引用修改其内容，必须额外防御性拷贝

什么时候不该用 List.of() / Map.of()

当集合需要动态增长、按需过滤、或与旧代码（尤其是依赖 ArrayList 特定行为如 ensureCapacity()）交互时，强行用不可变集合反而增加复杂度。

典型踩坑点：

• MyBatis 返回结果被包装成 List.of() 后传给前端分页工具，结果工具内部调用了 subList() 或 sort() —— 报 UnsupportedOperationException，因为 ListN 不支持这些操作（Java 16 前）
• Spring Boot 的 @ConfigurationProperties 绑定字段声明为 List，但初始化用了 List.of()，会导致后续 refresh 配置失败（框架尝试 clear/re-add）
• 日志框架（如 Logback）对集合做 toString() 时，某些版本对不可变集合的格式化有兼容问题，输出类似 ListN@1a2b3c 而非实际内容

不可变性的价值不在“永远不用改”，而在“改必须显式发生”。一旦你意识到某处数据本就不该被下游改动，List.of() 和 Map.of() 就是最轻量、最直接的契约表达——但得清楚它守的是哪条线，又在哪留了门。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《不可变集合防止数据篡改方法》文章吧，也可关注golang学习网公众号了解相关技术文章。