Java中创建不可修改集合的三种主流方式是：Collections.unmodifiableXXX()系列（包装视图，不阻原始修改）、Java 9+ List.of()/Set.of()/Map.of()（直接构造不可变实例，禁null和重复）、Stream.toList()（Java 16+，返回新不可变列表）。
Java中创建不可修改集合的三种主流方式
Java没有原生的“只读集合类型”，所有不可修改集合都是对已有集合的包装视图，底层仍依赖原始集合。一旦原始集合被修改，包装后的视图可能抛出UnsupportedOperationException，也可能出现不一致行为——这点极易被忽略。
最常用的是Collections.unmodifiableXXX()系列方法，它们返回的是即时快照式包装器；Java 9 引入的List.of()、Set.of()、Map.of()则直接构造不可变实例，更安全也更轻量。
-
Collections.unmodifiableList(list)：适用于已有ArrayList或LinkedList等可变集合，但需确保原始引用不再被使用 -
List.of("a", "b")：元素个数≤10时高效，内部用紧凑数组实现；超过10个元素会回退到ImmutableCollections.ListN -
Arrays.asList(...).toArray()不能直接传给unmodifiableList()来“加固”——因为Arrays.asList()返回的是固定大小的列表，本身就不支持add()/remove()，但set()仍可用
为什么Collections.unmodifiableList()修改原始集合会导致问题
这个包装器不复制数据，只是拦截写操作并抛异常。但它**不阻止原始集合被其他引用修改**。比如：
Listsource = new ArrayList<>(Arrays.asList("x", "y")); List unmod = Collections.unmodifiableList(source); source.add("z"); // 合法！unmod.size() 现在是 3，遍历时会包含 "z"
此时unmod看似只读，实则已“脏”。这种隐式耦合是调试时最难定位的问题之一。
立即学习“Java免费学习笔记（深入）”；
- 根本原因：
unmodifiableList()只是代理，不是副本 - 修复思路：若需真正隔离，必须做深拷贝（如
new ArrayList(source)再包装） - 注意
Stream.toList()（Java 16+）返回的是不可修改列表，但它是新集合，与源无关联
Java 9+ of()系列方法的限制和陷阱
List.of()、Set.of()、Map.of()返回的是JVM内置的不可变实现，不仅禁止写操作，连null都不允许——这是和unmodifiableXXX()的关键区别。
-
List.of("a", null)直接抛NullPointerException，而Collections.unmodifiableList(Arrays.asList("a", null))是合法的 -
Set.of(1, 2, 2)抛IllegalArgumentException（重复元素），unmodifiableSet(new HashSet(Arrays.asList(1,2,2)))不报错，但实际只存一个2 -
Map.of("k", "v")最多支持10个键值对；更多请用Map.ofEntries(Map.entry(k1,v1), ...)
如何安全地对外暴露集合字段
类内部持有可变集合、但对外只提供只读视图，是常见设计需求。错误做法是每次getter都调用Collections.unmodifiableList(this.items)——这会反复创建新包装器，且无法防止多次调用后原始集合被改。
- 推荐模式：在字段初始化时就构造不可变副本，例如
private final Listitems = List.of("a", "b"); - 若必须动态构建，用
new ArrayList(source)+Collections.unmodifiableList()组合，并确保source无外部引用 - 避免返回
this.items的任何可变视图，包括subList()、stream().collect(Collectors.toList())等——它们可能绕过保护逻辑
真正的不可变性不在接口名里，而在对象生命周期和引用控制中。哪怕用了of()，如果把返回的List转成ArrayList再暴露出去，一切防护就失效了。
