Java 9+ 中 Set.of()、List.of() 是创建不可变集合最直接方式，返回私有实现类，禁止修改和 null 元素；Collections.unmodifiableXXX 仅包装视图，需先复制再包装；Guava 提供更灵活的不可变集合支持。
Java 9+ 中用 Set.of()、List.of() 创建不可变集合最直接
Java 9 引入的工厂方法是创建不可变集合最简洁的方式，生成的对象既不可修改，也不允许 null 元素（会抛 NullPointerException）。
常见错误是误以为返回的是普通 ArrayList 或 HashSet —— 实际上它们是私有实现类（如 ImmutableCollections.ListN），不继承自标准集合子类，且所有修改操作（add()、remove()、clear() 等）都会立即抛出 UnsupportedOperationException。
实操建议：
-
List.of("a", "b", "c")创建固定大小、无重复限制的不可变列表；空集合用List.of() -
Set.of("x", "y")要求元素互异，否则编译期不报错，但运行时抛IllegalArgumentException - 若需含
null，或需要可变副本，必须改用其他方式（如Collections.unmodifiableXXX()包装后复制）
用 Collections.unmodifiableList() 包装已有集合要注意“防御性复制”
这个方法不创建新集合，只是返回一个包装视图（wrapper view）。如果原始集合后续被修改，不可变视图会同步反映变化——这常导致“看似不可变，实则被悄悄改掉”的问题。
立即学习“Java免费学习笔记（深入）”；
典型场景：把内部 ArrayList 字段通过该方法暴露给外部，但没做深拷贝。
实操建议：
- 务必先复制再包装：
private final List<String> data = Collections.unmodifiableList(new ArrayList<>(original));
- 不要对已包装对象再次调用
unmodifiableXXX，无意义且可能掩盖逻辑错误 - 该方式允许
null，也支持空集合，比of()更灵活，但性能略低（多一层代理开销）
Guava 的 ImmutableList.copyOf() 和 ImmutableSet.of() 支持 null 和构建器模式
如果你项目已引入 Guava，它的不可变集合更贴近实际工程需求：允许显式控制是否接受 null，提供 Builder 构建复杂结构，且底层做了优化（例如 ImmutableList 使用紧凑数组存储）。
容易踩的坑是混淆 copyOf() 和 copyOf(Iterable) 的行为差异：前者直接引用数组（若传入的是 ArrayList 内部数组，仍存在风险），后者总是安全复制。
实操建议：
- 优先用
ImmutableList.copyOf(collection)而非copyOf(array)，避免意外共享底层数组 - 需要动态构建时用
ImmutableList.builder().add(...).build()，比链式调用of()更清晰 - 注意 Guava 的
ImmutableSet.of()不检查重复（与 JDK 不同），重复元素会被保留为单个实例，但顺序不保证
不可变集合不是线程安全的银弹，要区分“不可变性”和“发布安全性”
很多人默认“不可变 = 天然线程安全”，但 Java 内存模型要求：即使对象状态不可变，若未正确发布（如未用 final 字段初始化、或在构造中逸出 this），其他线程仍可能看到部分构造的值。
尤其在静态工厂方法（如 List.of()）中，JDK 已确保安全发布；但自己手写不可变类时，必须将所有字段声明为 final，且不能在构造器中泄露 this。
真正容易被忽略的是：不可变集合无法防止其元素本身被修改。如果存的是可变对象（如 new ArrayList()），外部仍可通过引用修改其内容——不可变只作用于集合结构，不递归冻结元素。
