C# ConditionalWeakTable 用途及线程安全分析

ConditionalWeakTable 是 .NET 中用于为对象附加生命周期绑定元数据的线程安全集合，仅弱引用键、强引用值，键回收后条目自动移除；不支持枚举或 LINQ，适用于动态装饰对象，但需警惕值反向持有键导致的循环引用内存泄漏。

ConditionalWeakTable 是什么，为什么不用 Dictionary

ConditionalWeakTable<K, V> 是 .NET 提供的一个特殊集合类型，核心用途是「给任意对象附加生命周期绑定的元数据」。它不阻止键对象被 GC 回收，一旦键被回收，对应条目自动消失——这点和 Dictionary<object, T> 有本质区别：Dictionary 会强引用键，导致本该回收的对象滞留。

典型场景包括：为第三方类型（比如 FileStream 或用户自定义类）动态挂载上下文、诊断信息、AOP 行为钩子等，且不干预其生命周期。

• 键（K）必须是引用类型，且内部用弱引用来跟踪
• 值（V）是强引用，但键被回收后，整个条目从表中移除（即使值还活着）
• 不支持枚举（foreach）、Count 属性或 LINQ 查询——它不是通用容器，而是“附着式存储”

ConditionalWeakTable 的线程安全性

ConditionalWeakTable<K, V> 的所有公开方法（Add、GetValue、TryGetValue、Remove）都是线程安全的。内部使用细粒度锁 + 无锁路径混合实现，.NET Core 2.1+ 还进一步优化了读多写少场景的性能。

但要注意：线程安全仅保证单个方法调用原子性，不保证复合操作的原子性。例如下面这段代码就有竞态风险：

var table = new ConditionalWeakTable<object, int>();
if (!table.TryGetValue(obj, out _))
{
    table.Add(obj, ComputeValue()); // 可能被多个线程同时执行
}

正确做法是用 GetValue，它自带“首次调用初始化”语义：

var value = table.GetValue(obj, _ => ComputeValue());

• GetValue 内部确保：对同一键，最多只调用一次工厂函数，其余线程阻塞等待结果
• 工厂函数（Func<K, V>）内不能依赖外部可变状态，否则可能引发不可预期行为
• 如果工厂函数抛异常，该异常会被缓存并重抛；后续对该键的 GetValue 调用仍会抛出同一异常

常见误用和内存泄漏隐患

最隐蔽的问题不是线程安全，而是误以为值的生命周期也受弱引用保护。实际上：ConditionalWeakTable 只弱引用键，值是强引用。如果值反过来持有键的引用（比如闭包捕获、事件订阅、内部字段赋值），就会形成循环引用，导致键无法被 GC —— 弱引用失效，内存泄漏发生。

• 避免在值类型中保存对键的强引用，尤其注意 lambda、匿名类、委托实例
• 若值需监听键的事件，务必在键释放前手动解绑（但键释放不可控，推荐改用 WeakEventManager 或弱事件模式）
• 不要把它当缓存用：没有过期策略、不支持容量控制、不触发 GC 友好清理
• 调试时看不到条目？因为 Visual Studio 的调试器会临时强引用对象，干扰弱引用观察 —— 需用内存快照（dotMemory / VS Diagnostic Tools）验证实际存活情况

替代方案对比：WeakReference<T> vs ConditionalWeakTable

如果你只是想“弱持有某个对象”，用 WeakReference<T> 更轻量；但如果你想“给任意已有对象加字段”，ConditionalWeakTable 是唯一选择。

• WeakReference<T>：你主动创建、持有、查询，适合缓存单个对象引用
• ConditionalWeakTable<T, U>：你把对象当键“贴标签”，框架帮你管理弱关联，适合装饰/扩展未知对象
• 两者都不解决“值引用键”的循环问题，这始终要靠设计规避

真正容易被忽略的是：它的存在本身就意味着你在做“运行时对象增强”，这种模式会让代码路径更难追踪、GC 行为更难预测——上线前务必用真实负载压测内存驻留曲线。