Immutable Collections 的线程安全仅限于读操作，写操作（如 Add）返回新实例但不保证引用更新的原子性，需用 ImmutableInterlocked 等机制同步。

Immutable Collections 的线程安全是“读安全”，不是“写安全”

不可变集合（如 ImmutableList、ImmutableHashSet）本身不提供写操作的线程同步——所有“修改”方法（如 Add()、Remove()）都返回一个新实例，原实例不变。这意味着：多个线程可以同时读取同一个实例，无需加锁；但若多个线程并发调用 Add() 并试图“更新”同一个变量，结果不可预测。

• 错误写法：

  var list = ImmutableList.Create(1);
  // 多个线程同时执行：
  list = list.Add(2); // ❌ 竞态：list 赋值非原子操作

• 正确思路：用 Interlocked.CompareExchange 或 ConcurrentStack 等协调共享引用的更新，或直接用 ConcurrentDictionary + 不可变值组合
• 常见误判：以为 ImmutableList 像 ConcurrentBag 一样能自动处理并发写入——它不能

为什么 ImmutableList.Add() 不需要内部锁

因为它的实现不修改原有结构，而是生成新节点树（底层是平衡红黑树或数组分段结构）。每次 Add() 只分配新内存、复用未变部分，无共享状态写冲突。这带来两个关键事实：

• 所有只读方法（Count、this[index]、Contains()）天然线程安全，可被任意线程无锁调用
• 性能代价在“写”侧：频繁 Add() 会触发大量小对象分配，GC 压力上升；不适合高频更新场景
• 注意：构造过程（如 ImmutableList.CreateRange()）也不是完全无锁——内部可能用临时数组+拷贝，但这是瞬时行为，不影响后续读取的安全性

和 ConcurrentCollection 混用时的典型陷阱

开发者常把 ImmutableList 放进 ConcurrentDictionary>，以为双重保险。但问题出在“替换”逻辑上：

• 看似安全的代码：

  var dict = new ConcurrentDictionary>();
  dict.AddOrUpdate("key", _ => ImmutableList.Create(1), (_, old) => old.Add(2));

• 实际风险：如果多个线程同时触发 AddOrUpdate 的 update 委托，它们都基于同一个 old 实例计算新值，导致丢失中间更新（类似 ABA 问题）
• 解决方式：改用 ImmutableInterlocked 工具类，例如 ImmutableInterlocked.Update(ref list, l => l.Add(2))，它用 CAS 循环确保引用更新原子性

真正需要线程安全写入时，该选什么

如果业务要求“多个线程持续向集合添加元素，且最终要一份一致快照”，ImmutableList 单独用并不合适。更实用的组合是：

• 写入阶段用 ConcurrentQueue 或 ConcurrentBag（低开销、高吞吐）
• 读取/处理阶段再一次性转成不可变集合：

  var snapshot = ImmutableList.CreateRange(concurrentQueue.ToArray());

• 或者用 BlockingCollection 配合生产者-消费者模式，避免竞争逻辑侵入业务层

不可变集合的线程安全边界很清晰：它担保的是“值不可变”带来的读安全，而不是“引用更新”的原子性。一旦涉及多线程共享并修改同一个变量（哪怕它指向不可变对象），就必须引入额外同步机制——这点极易被忽略。

https://www.php.cn/faq/1996221.html