17370845950

event 的 += 和 -= 操作

本身线程安全，由 CLR 通过 Interlocked.CompareExchange 保证原子性；但事件触发和处理器逻辑不安全，需手动快照委托引用并防御空值，且自定义访问器会失去该保障。

event 的 += 和 -= 操作本身是线程安全的

CLR 保证 event 的订阅（+=）和取消订阅（-=）是原子操作，底层通过 Interlocked.CompareExchange 实现。这意味着多个线程同时调用 myEvent += handler 不会导致委托链损坏或 NullReferenceException。

但注意：这只是「修改事件字段」安全，不等于「触发事件」安全，也不等于「事件处理逻辑」安全。

• 如果在事件触发前，另一个线程刚执行了 -=，而你没做空检查，myEvent?.Invoke() 仍可能为 null（虽然概率低，但非零）
• 委托链内部的合并/拆分虽原子，但若多个线程反复高频订阅/取消，可能因引用竞争导致某次 Invoke 调用漏掉部分 handler（罕见，但 .NET Framework 4.5 以前有报告）
• .NET Core / .NET 5+ 对 MulticastDelegate 的操作做了更强一致性保证，但仍建议显式防御

触发 event 时必须手动判空并快照委托引用

直接写 MyEvent?.Invoke(args) 在多线程下存在竞态：判断非空后，另一线程可能立刻把 MyEvent 设为 null，导致 Invoke 抛出 NullReferenceException。

正确做法是先读取一次委托引用，再判空调用：

var handler = MyEvent;
if (handler != null)
{
    handler(args);
}

这个模式叫「委托快照（delegate snapshot）」，本质是避免两次读取字段带来的状态漂移。

• 不能用 lock(this) 或其他锁包裹整个 Invoke —— 会把调用方线程拖进你的锁，极易引发死锁或性能瓶颈
• 快照方式开销极小，且符合事件「fire-and-forget」语义
• 如果事件是 static，快照变量也应是局部的，不要缓存到字段里

委托指向的方法体不是自动线程安全的

委托本身只是方法指针 + 目标对象引用，它不提供任何同步机制。如果你的事件处理器里修改了共享字段、集合或 UI 控件，线程安全责任完全在你自己。

常见陷阱场景：

• UI 线程事件（如 WinForms Button.Click）在 UI 线程触发，但若你从后台线程触发自定义事件，处理器可能在非 UI 线程执行 → 直接访问 textBox.Text 抛 InvalidOperationException
• 多个线程触发同一事件，处理器中更新 List 未加锁 → IndexOutOfRangeException 或数据丢失
• 使用 async void 事件处理器，异常无法被外层捕获，且上下文切换可能放大竞态

解决方向取决于场景：
— UI 更新走 Control.Invoke 或 Dispatcher.Invoke
— 共享数据结构换用 ConcurrentQueue、ConcurrentDictionary
— 真需要锁时，优先用 ReaderWriterLockSlim 而非 lock，尤其读多写少

自定义 event 访问器要格外小心

一旦你用 add/remove 块显式实现事件（比如为了日志、限流或线程调度），所有线程安全假设都失效。CLR 不再介入，完全由你负责。

例如下面这段代码是危险的：

private EventHandler _handlers;
public event EventHandler MyEvent
{
    add { _handlers += value; } // 非原子！
    remove { _handlers -= value; }
}

因为 _handlers += value 是「读-改-写」三步操作，在多线程下会丢失更新。

• 必须手动同步：用 lock、Interlocked 或 ConcurrentQueue 管理委托列表
• 若想保持快照语义，add 中也要用快照方式合并，remove 中用 Delegate.Remove 并赋值回字段
• 更推荐的做法是：除非真有特殊需求，否则别手写访问器；用编译器生成的默认事件，只在触发处做快照

委托链的线程安全边界非常窄——只保订阅/取消动作，其余全是灰色地带。最常被忽略的是：你以为用了 event 就“自带同步”，结果在 Invoke 前没快照、处理器里乱改共享状态、或者手写访问器时把 += 当成原子操作。