更新

从C＃6开始，此问题的答案是：

SomeEvent?.Invoke(this, e);

我经常听到/阅读以下建议：

在检查null并触发事件之前，请务必复制事件。这将消除潜在的线程问题，即事件null在您检查空值和触发事件的位置之间的位置变为：

// Copy the event delegate before checking/calling
EventHandler copy = TheEvent;

if (copy != null)
    copy(this, EventArgs.Empty); // Call any handlers on the copied list

更新：我从阅读有关优化的内容中认为，这可能还要求事件成员具有可变性，但是Jon Skeet在回答中指出CLR不会优化副本。

但是，与此同时，为了使此问题发生，另一个线程必须执行以下操作：

// Better delist from event - don't want our handler called from now on:
otherObject.TheEvent -= OnTheEvent;
// Good, now we can be certain that OnTheEvent will not run...

实际的顺序可能是这种混合：

// Copy the event delegate before checking/calling
EventHandler copy = TheEvent;

// Better delist from event - don't want our handler called from now on:
otherObject.TheEvent -= OnTheEvent;    
// Good, now we can be certain that OnTheEvent will not run...

if (copy != null)
    copy(this, EventArgs.Empty); // Call any handlers on the copied list

关键在于OnTheEvent作者取消订阅之后，但是他们只是专门取消订阅以避免这种情况的发生。当然，真正需要的是在add和中remove访问。此外，如果在触发事件时持有锁，则可能会出现死锁。

那么这是《货运崇拜编程》吗？似乎是这样-很多人必须采取这一步骤来保护自己的代码免受多个线程的侵害，而在我看来，实际上，在将事件用作多线程设计的一部分之前，事件需要比这多得多的关注。因此，那些没有特别注意的人也可能会忽略此建议-对于单线程程序来说这根本不是问题，并且实际上，由于volatile大多数在线示例代码中都没有，因此该建议可能没有完全没有效果。

（并且delegate { }在成员声明中分配空值是否更简单，这样您就不必首先检查null？）

更新：如果不清楚，我确实掌握了建议的意图-避免在所有情况下都出现空引用异常。我的观点是，仅当另一个线程从该事件中退出时，才会发生此特定的null引用异常，而这样做的唯一原因是确保不会通过该事件接收到进一步的调用，而该技术显然无法实现。您可能会隐藏种族状况-最好公开一下！空异常有助于检测对组件的滥用。如果希望保护组件免受滥用，则可以遵循WPF的示例-将线程ID存储在构造函数中，如果另一个线程尝试直接与组件进行交互，则抛出异常。否则，实现一个真正的线程安全组件（不是一件容易的事）。

因此，我认为仅执行此复制/检查惯用语便是一种狂热的编程，这会给您的代码增加混乱和噪音。要真正保护自己免受其他线程的攻击，需要进行大量工作。

更新以回应Eric Lippert的博客文章：

因此，关于事件处理程序，我错过了一件主要的事情：“即使在事件未订阅后，事件处理程序也必须在被调用时保持健壮”，因此，显然，我们只需要关心事件的可能性代表被null。对事件处理程序的要求是否记录在任何地方？

因此：“还有其他方法可以解决此问题；例如，初始化处理程序以使其具有从未删除的空动作。但是，执行空检查是标准模式。”

因此，我的问题剩下的一个片段是，为什么要显式-空检查“标准模式”？另一种方法是分配空的委托人，只需= delegate {}要将其添加到事件声明中，这样就消除了在引发事件的每个位置上的一堆臭臭的仪式。确保空委托的实例化很便宜。还是我还缺少什么？

当然一定是（正如Jon Skeet所建议的那样），这仅仅是.NET 1.x的建议还没有像2005年那样被淘汰？

由于条件的原因，不允许JIT执行您在第一部分中讨论的优化。我知道这是在不久前提出来的，但这是无效的。（前一段时间我曾与Joe Duffy或Vance Morrison进行过核对；我不记得是哪个。）

如果没有volatile修饰符，则所获取的本地副本可能会过时，仅此而已。它不会导致NullReferenceException。

是的，肯定有比赛条件-但总会存在。假设我们将代码更改为：

TheEvent(this, EventArgs.Empty);

现在假设该委托的调用列表有1000个条目。在另一个线程取消订阅列表末尾的处理程序之前，很有可能在列表开头的操作已经执行。但是，该处理程序将仍然执行，因为它将是一个新列表。（代表们是一成不变的。）据我所知，这是不可避免的。

使用空的委托当然可以避免无效检查，但不能解决竞争条件。它还不能保证您始终“看到”变量的最新值。

我看到很多人都倾向于这样做的扩展方法...

public static class Extensions   
{   
  public static void Raise<T>(this EventHandler<T> handler, 
    object sender, T args) where T : EventArgs   
  {   
    if (handler != null) handler(sender, args);   
  }   
}

那给你更好的语法来引发事件...

MyEvent.Raise( this, new MyEventArgs() );

并且也取消了本地副本，因为它是在方法调用时捕获的。

“为什么显式-空检查'标准模式'？”

我怀疑这可能是因为空检查性能更高。

如果在创建事件时始终为事件委派空的委托，则将产生一些开销：

• 构造空委托的成本。
• 构建包含它的委托链的成本。
• 每次引发事件时调用无意义的委托的成本。

（请注意，UI控件通常具有大量事件，其中大多数事件从未订阅。必须为每个事件创建虚拟订阅者，然后调用它，这可能会严重打击性能。）

我进行了一些粗略的性能测试，以了解subscribe-empty-delegate方法的影响，这是我的结果：

Executing 50000000 iterations . . .
OnNonThreadSafeEvent took:      432ms
OnClassicNullCheckedEvent took: 490ms
OnPreInitializedEvent took:     614ms <--
Subscribing an empty delegate to each event . . .
Executing 50000000 iterations . . .
OnNonThreadSafeEvent took:      674ms
OnClassicNullCheckedEvent took: 674ms
OnPreInitializedEvent took:     2041ms <--
Subscribing another empty delegate to each event . . .
Executing 50000000 iterations . . .
OnNonThreadSafeEvent took:      2011ms
OnClassicNullCheckedEvent took: 2061ms
OnPreInitializedEvent took:     2246ms <--
Done

请注意，对于零个或一个订阅者（对于UI控件来说是常见的，事件很多），用空的委托预先初始化的事件要慢得多（超过5000万次迭代...）

有关更多信息和源代码，请访问此博客文章。NET事件调用线程安全性是我在提出此问题的前一天发布的（！）

（我的测试设置可能有缺陷，因此可以随时下载源代码并亲自检查它。非常感谢您提供任何反馈。）

我真的很喜欢这篇读物-不！即使我需要它与称为事件的C＃功能一起使用！

为什么不在编译器中解决此问题？我知道有MS人士在阅读这些帖子，所以请不要对此发火！

1-空问题）为什么不首先将事件设置为.Empty而不是null？为了进行空检查或必须= delegate {}在声明上粘贴a，将保存几行代码？让编译器处理Empty情况，IE不执行任何操作！如果这对事件的创建者来说很重要，他们可以检查.Empty并做任何自己关心的事情！否则，所有的null检查/委托添加都会解决该问题！

老实说，我厌倦了每次事件都必须执行此操作-又名样板代码！

public event Action<thisClass, string> Some;
protected virtual void DoSomeEvent(string someValue)
{
  var e = Some; // avoid race condition here! 
  if(null != e) // avoid null condition here! 
     e(this, someValue);
}

2-竞赛条件问题）我阅读了Eric的博客文章，我同意H（处理程序）在取消引用自己时应进行处理，但是不能将事件设为不可变的/线程安全的吗？IE，在其创建时设置了一个锁定标志，以便无论何时调用它，它在执行时都将锁定所有订阅和取消订阅该订阅？

结论，

现代语言是否不应该为我们解决此类问题？

在C＃6及更高版本中，可以使用new ?.运算符来简化代码，如下所示：

TheEvent?.Invoke(this, EventArgs.Empty);

这是MSDN文档。

根据杰弗里·里希特（Jeffrey Richter）在通过C＃编写的CLR书中，正确的方法是：

// Copy a reference to the delegate field now into a temporary field for thread safety
EventHandler<EventArgs> temp =
Interlocked.CompareExchange(ref NewMail, null, null);
// If any methods registered interest with our event, notify them
if (temp != null) temp(this, e);

因为它强制引用副本。有关更多信息，请参见书中的“事件”部分。

我一直在使用这种设计模式来确保事件处理程序在退订后不会执行。到目前为止，它运行良好，尽管我还没有尝试任何性能分析。

private readonly object eventMutex = new object();

private event EventHandler _onEvent = null;

public event EventHandler OnEvent
{
  add
  {
    lock(eventMutex)
    {
      _onEvent += value;
    }
  }

  remove
  {
    lock(eventMutex)
    {
      _onEvent -= value;
    }
  }

}

private void HandleEvent(EventArgs args)
{
  lock(eventMutex)
  {
    if (_onEvent != null)
      _onEvent(args);
  }
}

这些天来，我主要使用的是Mono for Android，当您将View的Activity发送到后台后尝试更新View时，Android似乎不喜欢它。

这种做法与强制执行特定顺序无关。它实际上是在避免空引用异常。

人们关心空参考异常而不是种族状况的背后原因需要进行深入的心理学研究。我认为这与解决空引用问题要容易得多有关。解决此问题后，他们会在代码上悬挂一个大的“任务完成”横幅，并解压缩其飞行服。

注意：解决竞争条件可能涉及使用同步标志跟踪处理程序是否应运行

所以我在这里参加聚会有点晚了。:)

至于使用null而不是null对象模式来表示没有订阅者的事件，请考虑这种情况。您需要调用一个事件，但是构造对象（EventArgs）并非易事，通常情况下，您的事件没有订阅者。如果您可以优化代码以检查是否有任何订阅者，然后再致力于构造自变量和调用事件，这将对您有所帮助。

考虑到这一点，一种解决方案是说“嗯，零个订户用null表示”。然后只需执行空检查，然后再执行昂贵的操作即可。我想执行此操作的另一种方法是在Delegate类型上具有Count属性，因此，仅当myDelegate.Count> 0时，才执行昂贵的操作。使用Count属性是解决原始问题的一种不错的模式允许优化，它还具有可以被调用而不会引起NullReferenceException的不错的属性。

但是请记住，由于委托是引用类型，因此它们可以为空。也许根本没有什么好办法可以将这一事实隐藏在幕后，并且仅支持事件的空对象模式，因此，替代方法可能是迫使开发人员同时检查零订户和零订户。那将比目前的情况还要糟糕。

注意：这纯粹是猜测。我不参与.NET语言或CLR。

对于单线程应用程序，您是正确的，这不是问题。

但是，如果您要制作一个暴露事件的组件，则不能保证该组件的使用者不会使用多线程，在这种情况下，您需要为最坏的情况做准备。

使用空委托确实可以解决问题，但也会导致每次调用事件时性能下降，并且可能会对GC产生影响。

您是正确的，消费者trie dto取消订阅是为了使这种情况发生，但是，如果他们超过了临时副本，则认为该消息已经在传输中。

如果您不使用临时变量，并且不使用空的委托，而有人取消订阅，则会得到null引用异常，这是致命的，因此我认为这样做值得。

我从来没有真正考虑过这是一个大问题，因为我通常只在可重用组件上的静态方法（等）中防止此类潜在的线程错误，并且我不进行静态事件。

我做错了吗？

将所有活动都安排在施工中，不要理会它们。正如我将在本文的最后一段中解释的那样，Delegate类的设计可能无法正确处理任何其他用法。

首先，当事件处理程序必须已经就是否/如何响应通知做出同步决策时，尝试拦截事件通知毫无意义。

任何可能被通知的东西都应该被通知。如果您的事件处理程序正确地处理了通知（即，他们可以访问权威应用程序状态并仅在适当的时候进行响应），则可以随时通知它们并相信它们将正确响应。

唯一不应该通知处理程序已发生事件的时间是，如果该事件实际上尚未发生！因此，如果您不希望收到处理程序的通知，请停止生成事件（即首先禁用控件或负责检测和使事件变为现实的任何操作）。

老实说，我认为Delegate类是不可挽救的。合并/转换为MulticastDelegate是一个巨大的错误，因为它有效地将事件的（有用的）定义从单个时刻发生的事情更改为某个跨时间发生的事情。这样的更改需要一种同步机制，该机制可以在逻辑上将其折叠回单个瞬间，但是MulticastDelegate缺少任何这种机制。同步应涵盖事件发生的整个时间范围或瞬间，以便一旦应用程序做出同步决定以开始处理事件，它便会完全（以事务方式）完成处理。由于黑盒是MulticastDelegate / Delegate混合类，因此这几乎是不可能的，因此坚持使用单用户和/或实现自己的MulticastDelegate类型，该类型具有一个同步句柄，可以在使用/修改处理程序链时将其取出。我建议这样做，因为替代方法是在所有处理程序中冗余地实现同步/事务完整性，这将是荒谬的/不必要的复杂。

请在此处查看：http : //www.danielfortunov.com/software/%24daniel_fortunovs_adventures_in_software_development/2009/04/23/net_event_invocation_thread_safety 这是正确的解决方案，应始终使用它代替所有其他解决方法。

“您可以使用不执行任何操作的匿名方法初始化内部调用列表，以确保内部调用列表始终至少具有一个成员。因为没有外部方可以引用匿名方法，所以没有外部方可以删除该方法，因此委托永远不会为空。” — JuvalLöwy编写的.NET Components，第二版

public static event EventHandler<EventArgs> PreInitializedEvent = delegate { };  

public static void OnPreInitializedEvent(EventArgs e)  
{  
    // No check required - event will never be null because  
    // we have subscribed an empty anonymous delegate which  
    // can never be unsubscribed. (But causes some overhead.)  
    PreInitializedEvent(null, e);  
}  

我不认为问题仅限于C＃“事件”类型。取消该限制，为什么不稍微重新发明轮子并按照这些原则做些什么呢？

安全地引发事件线程-最佳实践

• 能够在提升期间（取消竞争条件）从任何线程进行订阅/取消订阅
• 在类级别上+ =和-=的运算符重载。
• 通用调用方定义的委托

感谢您的有益讨论。我最近正在研究此问题，并制作了以下类，该类稍慢一些，但可以避免调用已处置的对象。

这里的要点是，即使引发事件，也可以修改调用列表。

/// <summary>
/// Thread safe event invoker
/// </summary>
public sealed class ThreadSafeEventInvoker
{
    /// <summary>
    /// Dictionary of delegates
    /// </summary>
    readonly ConcurrentDictionary<Delegate, DelegateHolder> delegates = new ConcurrentDictionary<Delegate, DelegateHolder>();

    /// <summary>
    /// List of delegates to be called, we need it because it is relatevely easy to implement a loop with list
    /// modification inside of it
    /// </summary>
    readonly LinkedList<DelegateHolder> delegatesList = new LinkedList<DelegateHolder>();

    /// <summary>
    /// locker for delegates list
    /// </summary>
    private readonly ReaderWriterLockSlim listLocker = new ReaderWriterLockSlim();

    /// <summary>
    /// Add delegate to list
    /// </summary>
    /// <param name="value"></param>
    public void Add(Delegate value)
    {
        var holder = new DelegateHolder(value);
        if (!delegates.TryAdd(value, holder)) return;

        listLocker.EnterWriteLock();
        delegatesList.AddLast(holder);
        listLocker.ExitWriteLock();
    }

    /// <summary>
    /// Remove delegate from list
    /// </summary>
    /// <param name="value"></param>
    public void Remove(Delegate value)
    {
        DelegateHolder holder;
        if (!delegates.TryRemove(value, out holder)) return;

        Monitor.Enter(holder);
        holder.IsDeleted = true;
        Monitor.Exit(holder);
    }

    /// <summary>
    /// Raise an event
    /// </summary>
    /// <param name="args"></param>
    public void Raise(params object[] args)
    {
        DelegateHolder holder = null;

        try
        {
            // get root element
            listLocker.EnterReadLock();
            var cursor = delegatesList.First;
            listLocker.ExitReadLock();

            while (cursor != null)
            {
                // get its value and a next node
                listLocker.EnterReadLock();
                holder = cursor.Value;
                var next = cursor.Next;
                listLocker.ExitReadLock();

                // lock holder and invoke if it is not removed
                Monitor.Enter(holder);
                if (!holder.IsDeleted)
                    holder.Action.DynamicInvoke(args);
                else if (!holder.IsDeletedFromList)
                {
                    listLocker.EnterWriteLock();
                    delegatesList.Remove(cursor);
                    holder.IsDeletedFromList = true;
                    listLocker.ExitWriteLock();
                }
                Monitor.Exit(holder);

                cursor = next;
            }
        }
        catch
        {
            // clean up
            if (listLocker.IsReadLockHeld)
                listLocker.ExitReadLock();
            if (listLocker.IsWriteLockHeld)
                listLocker.ExitWriteLock();
            if (holder != null && Monitor.IsEntered(holder))
                Monitor.Exit(holder);

            throw;
        }
    }

    /// <summary>
    /// helper class
    /// </summary>
    class DelegateHolder
    {
        /// <summary>
        /// delegate to call
        /// </summary>
        public Delegate Action { get; private set; }

        /// <summary>
        /// flag shows if this delegate removed from list of calls
        /// </summary>
        public bool IsDeleted { get; set; }

        /// <summary>
        /// flag shows if this instance was removed from all lists
        /// </summary>
        public bool IsDeletedFromList { get; set; }

        /// <summary>
        /// Constuctor
        /// </summary>
        /// <param name="d"></param>
        public DelegateHolder(Delegate d)
        {
            Action = d;
        }
    }
}

用法是：

    private readonly ThreadSafeEventInvoker someEventWrapper = new ThreadSafeEventInvoker();
    public event Action SomeEvent
    {
        add { someEventWrapper.Add(value); }
        remove { someEventWrapper.Remove(value); }
    }

    public void RaiseSomeEvent()
    {
        someEventWrapper.Raise();
    }

测试

我以以下方式对其进行了测试。我有一个线程可以创建和销毁这样的对象：

var objects = Enumerable.Range(0, 1000).Select(x => new Bar(foo)).ToList();
Thread.Sleep(10);
objects.ForEach(x => x.Dispose());

在Bar（侦听器对象）构造函数中，我订阅SomeEvent（如上所示实现）并在下进行退订Dispose：

    public Bar(Foo foo)
    {
        this.foo = foo;
        foo.SomeEvent += Handler;
    }

    public void Handler()
    {
        if (disposed)
            Console.WriteLine("Handler is called after object was disposed!");
    }

    public void Dispose()
    {
        foo.SomeEvent -= Handler;
        disposed = true;
    }

我也有几个线程在循环中引发事件。

所有这些动作都是同时执行的：创建并销毁了许多侦听器，同时触发了事件。

如果存在比赛条件，我应该在控制台中看到一条消息，但该消息为空。但是，如果像往常一样使用clr事件，我将看到警告消息。因此，我可以得出结论，可以在c＃中实现线程安全事件。

你怎么看？