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
(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配合生产者-消费者模式，避免竞争逻辑侵入业务层
