不可变集合创建与使用技巧

Java 9 引入的 List.of() 和 Map.of() 提供了一种轻量、高效且语义清晰的方式创建不可变集合，能从根本上杜绝集合结构被意外修改（如 add/remove/put 抛出 UnsupportedOperationException），天然线程安全并增强代码健壮性；但需注意其限制——不支持 null、参数数量有限（List.of 最多 10 个）、Map.of 在 Java 14+ 编译期即拦截重复 key，且仅防护集合容器层变更，无法阻止可变元素内部状态被篡改；它最适合配置项、状态码映射等只读场景，却在动态操作、框架集成或需 deep immutability 的场合存在明显边界，真正安全需“容器不可变 + 元素不可变”双层保障。

为什么 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学习网公众号，带你了解更多关于的知识点！