Immutable Collections 的线程安全是“读安全”，不是“写安全”
不可变集合（如
ImmutableList<t></t>、
ImmutableHashSet<t></t>）本身不提供写操作的线程同步——所有“修改”方法（如
Add()、
Remove()）都返回一个新实例，原实例不变。这意味着：多个线程可以同时读取同一个实例，无需加锁；但若多个线程并发调用
Add()并试图“更新”同一个变量，结果不可预测。 错误写法：
var list = ImmutableList.Create<int>(1); // 多个线程同时执行： list = list.Add(2); // ❌ 竞态：list 赋值非原子操作正确思路：用
Interlocked.CompareExchange或
ConcurrentStack<t></t>等协调共享引用的更新，或直接用
ConcurrentDictionary+ 不可变值组合 常见误判：以为
ImmutableList<t></t>像
ConcurrentBag<t></t>一样能自动处理并发写入——它不能
为什么 ImmutableList<t>.Add()</t>
不需要内部锁
因为它的实现不修改原有结构，而是生成新节点树（底层是平衡红黑树或数组分段结构）。每次
Add()只分配新内存、复用未变部分，无共享状态写冲突。这带来两个关键事实： 所有只读方法（
Count、
this[index]、
Contains()）天然线程安全，可被任意线程无锁调用 性能代价在“写”侧：频繁
Add()会触发大量小对象分配，GC 压力上升；不适合高频更新场景 注意：构造过程（如
ImmutableList.CreateRange()）也不是完全无锁——内部可能用临时数组+拷贝，但这是瞬时行为，不影响后续读取的安全性
和 ConcurrentCollection
混用时的典型陷阱
开发者常把
ImmutableList<t></t>放进
ConcurrentDictionary<string immutablelist>></string>，以为双重保险。但问题出在“替换”逻辑上： 看似安全的代码：
var dict = new ConcurrentDictionary<string, ImmutableList<int>>();
dict.AddOrUpdate("key", _ => ImmutableList.Create<int>(1), (_, old) => old.Add(2));
实际风险：如果多个线程同时触发 AddOrUpdate的 update 委托，它们都基于同一个
old实例计算新值，导致丢失中间更新（类似 ABA 问题） 解决方式：改用
ImmutableInterlocked工具类，例如
ImmutableInterlocked.Update(ref list, l => l.Add(2))，它用 CAS 循环确保引用更新原子性
真正需要线程安全写入时，该选什么
如果业务要求“多个线程持续向集合添加元素，且最终要一份一致快照”，
ImmutableList单独用并不合适。更实用的组合是： 写入阶段用
ConcurrentQueue<t></t>或
ConcurrentBag<t></t>（低开销、高吞吐） 读取/处理阶段再一次性转成不可变集合：
var snapshot = ImmutableList.CreateRange(concurrentQueue.ToArray());或者用
BlockingCollection<t></t>配合生产者-消费者模式，避免竞争逻辑侵入业务层 不可变集合的线程安全边界很清晰：它担保的是“值不可变”带来的读安全，而不是“引用更新”的原子性。一旦涉及多线程共享并修改同一个变量（哪怕它指向不可变对象），就必须引入额外同步机制——这点极易被忽略。
