Java9List.of和Map.of使用教程

Java 9 引入的 `List.of` 和 `Map.of` 是创建轻量级不可变集合的高效新方式，它们在编译期校验 null、运行时彻底禁止修改（任何增删改操作均抛出 `UnsupportedOperationException`），并针对典型场景做了语义优化——但这也意味着它们不是 `Arrays.asList` 的简单替代品：`List.of` 更安全却更严格（拒绝 null、不共享底层数组），`Map.of` 便捷但上限 10 键值对（超限需改用 `Map.ofEntries`），且二者与旧集合在 `hashCode`/`equals` 行为上存在隐蔽差异，可能引发哈希容器中的意外行为；因此，它们最适合配置常量、函数默认参数等“写后即固定”的场景，而一旦涉及后续修改、兼容老旧代码或对哈希一致性有强要求，就需谨慎评估或主动包装为可变集合。

为什么 List.of 创建的集合不能增删改

因为 List.of 返回的是不可变（immutable）集合，底层不是 ArrayList 或 LinkedList，而是一个私有静态内部实现类（如 ImmutableCollections.ListN），所有修改操作（add、remove、set）都会直接抛出 UnsupportedOperationException。

• 常见错误现象：Exception in thread "main" java.lang.UnsupportedOperationException 出现在调用 list.add(...) 后
• 使用场景：适合配置项、枚举常量、函数参数默认值等「写后即固定」的数据
• 注意：哪怕只传一个 null 元素，List.of(null) 也会抛 NullPointerException —— 它在构造时就做空值校验

Map.of 最多只能建 10 个键值对？

是的。Map.of 重载方法只提供从 0 到 10 个键值对的版本（Map.of()、Map.of(k1,v1)、…、Map.of(k1,v1, ..., k10,v10)）。超过就得换 Map.ofEntries。

• 常见错误现象：写 Map.of(k1,v1, k2,v2, ..., k11,v11) → 编译失败，提示“no suitable method found”
• 正确做法：用 Map.ofEntries 配合 Map.entry，例如 Map.ofEntries(Map.entry(k1,v1), Map.entry(k2,v2), ...)
• 性能影响：两者都返回不可变 Map，但 Map.ofEntries 多一层数组封装，开销微乎其微，别为这个犹豫

和 Arrays.asList 比，List.of 真的更安全吗

更安全，但安全点不同。Arrays.asList 返回的是可变集合（支持 set，不支持 add/remove），且底层数组引用未隔离；List.of 彻底不可变，也不暴露内部结构。

• 典型坑：Arrays.asList(arr) 返回的 list 修改元素会同步改原数组；List.of(arr) 是把整个 arr 当作一个元素放进 list（除非你显式展开）
• 参数差异：Arrays.asList("a", "b") 接受可变参数，但泛型推导弱；List.of("a", "b") 泛型更严格，且拒绝 null
• 兼容性：两者都是 Java 9+ 可用，但 List.of 在 Android（API 26+）也支持，Arrays.asList 更老，但行为更易误读

什么时候不该用 Map.of 或 List.of

当你要后续修改、或需要保持插入顺序但又不确定 key 是否重复时，别硬套。它们不是语法糖，是语义承诺：「这数据从现在起就不该变了」。

• 容易被忽略的点：不可变集合不重写 hashCode/equals 的逻辑缺陷——比如两个内容相同的 List.of(1,2) 和 Arrays.asList(1,2)，equals 返回 true，但它们的 hashCode 不同（因底层类不同），用在 HashSet 或作为 HashMap key 时可能出意料结果
• 如果只是临时组装再立刻传给某个 API，且该 API 内部会拷贝或只读访问，用 List.of 没问题；但如果要反复复用、或传入旧代码（可能偷偷修改），先 new ArrayList(List.of(...)) 更稳妥

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《Java9List.of和Map.of使用教程》文章吧，也可关注golang学习网公众号了解相关技术文章。