Java Stream 无法真正替代不可变集合操作，因其依赖可变数据源、不保证输入不可变、无结构共享，且频繁 collect 会带来高 GC 压力；标准库缺乏持久化数据结构，unmodifiableXXX 仅为只读视图，并非真正不可变。
Java Stream 无法真正替代不可变集合操作
Java 的 Stream 看似支持函数式风格，但底层仍是基于可变数据源的惰性求值——一旦原始集合被修改，Stream 可能抛出 ConcurrentModificationException，或返回不一致结果。这不是 bug，是设计使然：它不保证输入不可变，也不提供结构共享。
常见错误现象：stream().map(...).collect(Collectors.toList()) 看似“转换”，实则每次新建对象；若反复对同一 ArrayList 做类似操作，内存压力明显，且无历史版本保留能力。
- 使用场景：适合一次性数据转换（如 API 响应组装），不适合需要多次回溯、撤销、分支计算的逻辑
- 参数差异：
Collectors.toUnmodifiableList()只防写入，不防底层数组被反射篡改；而真正的不可变集合（如ImmutableList）在构造时就切断所有可变入口 - 性能影响：频繁调用
stream()+collect()比直接用持久化结构（如 PCollections）多 2–3 倍 GC 压力
java.util.Collections.unmodifiableXXX 是假不可变
Collections.unmodifiableList() 这类方法返回的只是“只读视图”，不是新集合。它内部仍持原始 ArrayList 引用，一旦原集合被其他代码修改，视图立刻失效——这是最常被忽略的坑。
典型错误：把 unmodifiableList(new ArrayList(src)) 当作安全副本传给下游，结果上游某处还在往 src 添加元素，下游拿到的数据突然多了一项。
立即学习“Java免费学习笔记（深入）”；
- 真正安全的做法是复制+封装：用
new ArrayList(original)先深拷贝（注意元素是否可变），再套一层unmodifiable - 兼容性风险：JDK 9+ 的
List.of()返回的是紧凑不可变实现，但不支持null，且无法扩容；和老版Arrays.asList()行为不一致 - 不能用于递归不可变：如果集合里存的是可变对象（比如
Map），外部仍可通过get(0).put("k", "v")修改内部状态
Java 标准库没有持久化数据结构原生支持
像 Clojure 的 vector 或 Scala 的 Vector 那种“修改返回新实例+共享大部分节点”的结构，Java 标准库一个都没有。所有 add/remove 操作都意味着完整复制或数组扩容。
这导致在需要频繁更新又需保留旧版本的场景（比如配置快照、事件溯源中间状态），只能靠手动 clone 或第三方库，否则极易写出隐藏的内存泄漏。
- 可用替代：PCollections（轻量、纯 Java）、Cyclops（集成更好但依赖多）、或者用
TreeSet/TreeMap借助比较器模拟有序持久行为（仅限特定排序需求） - 性能陷阱：自己写“不可变包装类”时若重写
equals()和hashCode()不小心用了Arrays.deepEquals()，大数据量下会退化成 O(n²) - 编译期无保障：即使用了
@Immutable注解（如 Immutables.org），也只是生成类，运行时仍可能被反射或序列化绕过
Stream.collect() 的并发收集器不是线程安全的“不可变构建”
Collectors.toConcurrentMap() 或 parallelStream().collect(...) 看似能并发生成结果，但它不等于“构建不可变集合”。最终返回的 ConcurrentHashMap 本身是可变的，且并行过程中的中间合并可能丢失顺序或触发竞态（尤其用自定义 Supplier + BiConsumer 时）。
错误认知：“用了 parallelStream 就天然函数式”，其实只是把副作用从单线程搬到了多线程，问题更难复现而已。
- 正确姿势：如需并发构建不可变结果，先用线程安全容器暂存（如
CopyOnWriteArrayList），最后统一转成List.of()或ImmutableList.copyOf() - 参数陷阱：
Collectors.collectingAndThen()的装饰函数若含副作用（比如日志打印），会在每个线程局部 collector 中执行多次，不是只在最终合并时跑一次 - 别指望 JIT 优化掉重复创建：JVM 不会对
stream().map(...).collect()链路做跨方法逃逸分析，每次都是新对象
真正卡住的地方从来不是语法，而是 Java 集合的设计契约本身——它默认可变、默认共享、默认不承诺结构一致性。想用函数式思维，就得主动切断这些默认，而不是靠包装方法假装安全。
