Java不可变集合用法：List.of与Map.of详解

Java 9 引入的 List.of 和 Map.of 并非简单的语法糖，而是强契约型不可变集合工厂方法：它们返回高度优化的私有不可变实例，严格禁止 null 元素或键值（JDK 14 前甚至编译即报错），任何 add/remove 操作均抛出 UnsupportedOperationException；适用于默认参数、配置常量、测试断言等只读场景，性能优异但参数数量受限（最多10个），真正挑战在于开发者需从“先创建后防护”转向“设计即不可变”的思维转变——选了它们，就等于签下了内容与结构终身不变的协议。

List.of 和 Map.of 是 Java 9 引入的不可变集合工厂方法，不是“字面量”，也不支持 null 元素或键值 —— 这是绝大多数人踩坑的第一步。

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

它返回的是 JVM 内部实现的私有不可变类（比如 ImmutableCollections.ListN），所有修改操作都直接抛 UnsupportedOperationException。这不是限制，而是设计契约：一旦创建，生命周期内结构与内容必须固定。

常见错误现象：

• 调用 list.add("x") 报错：java.lang.UnsupportedOperationException
• 试图用 ArrayList 构造器包装它再修改：new ArrayList(List.of(1,2)) —— 可行，但已脱离“不可变”语义，别混淆目的

使用场景：

• 作为方法参数默认值（避免被意外修改）
• 配置项、枚举常量集合等只读数据容器
• 单元测试中构造预期结果集（断言时不怕被副作用污染）

Map.of 对 key 和 value 的 null 限制很严格

Map.of() 在 Java 9–14 中完全禁止 null 键和 null 值；Java 15+ 才通过 Map.ofEntries(Map.entry(k,v)) 绕过（但 entry 本身仍不接受 null）。这点和 HashMap 或 Map.ofNullable（Java 19+）有本质区别。

容易踩的坑：

• Map.of("a", null) 直接编译失败（JDK 14 及以前）或运行时报 NullPointerException
• 误以为 Map.of("k1","v1","k2",null) 能“跳过”第二对 —— 实际会立即中断，不构造任何 map
• 在 Spring Boot 配置类里硬写 Map.of("timeout", env.getProperty("api.timeout"))，而该属性为空时崩掉

替代方案（按 JDK 版本）：

• JDK 9–14：Map.ofEntries(Map.entry("k1","v1"))（仍不能含 null）
• JDK 19+：Map.ofNullable("k1", null)（允许单个 null 值，但 key 仍不可为 null）
• 通用兜底：Collections.unmodifiableMap(new HashMap(){...})，自己判空再 put

性能与兼容性：小集合快，大集合别硬套

List.of 和 Map.of 的底层做了高度特化：元素少时用栈内对象（如 List1, Map2），无迭代器开销、无扩容逻辑，比 new ArrayList(Arrays.asList(...)) 快 2–3 倍。但超过 10 个元素后，可读性和维护性迅速下降。

参数差异带来的实际影响：

• List.of(1,2,3) 最多支持 10 个参数；超了必须用 List.ofArray(new Integer[]{...})（Java 10+）
• Map.of("a",1,"b",2) 同样限 10 个参数（即 5 对）；更多请改用 Map.ofEntries(entry1,entry2,...)
• 所有参数在调用时求值 —— 如果传入的是耗时计算或有副作用的表达式（如 service.fetch()），失败则整个构造失败，没有“部分成功”概念

真正麻烦的不是语法，是思维切换：它们不是语法糖，而是契约型 API。你得提前决定“这个集合要不要被改”，而不是先创建再补防御。一旦选了 List.of，就等于签了不可变协议 —— 后续所有协作代码都得按这个前提来。

理论要掌握，实操不能落！以上关于《Java不可变集合用法：List.of与Map.of详解》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！