请看这里:http://www.danielfortunov.com/software/%24daniel_fortunovs_adventures_in_software_development/2009/04/23/net_event_invocation_thread_safety 这是正确的解决方案，应该经常使用，而不是所有其他变通方法。

通过使用不做任何事情的匿名方法初始化内部调用列表，可以确保它始终至少有一个成员。因为没有外部方可以引用匿名方法，也没有外部方可以删除该方法，因此委托永远不会为空。” -编程。net组件，第二版，由Juval Löwy

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);  
}  

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

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);
  }
}

这些天我主要是在Android上使用Mono，当你试图在Activity被发送到后台后更新视图时，Android似乎不喜欢它。

在c# 6及以上版本中，可以使用new ?运算符如下:

TheEvent ?。调用(这,EventArgs.Empty);

这里是MSDN文档。

把你在工地的所有活动都打过去，别插手。Delegate类的设计不可能正确地处理任何其他用法，这一点我将在本文的最后一段解释。

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

任何可能被通知的事情，都应该被通知。如果您的事件处理程序正确地处理了通知(例如，它们可以访问权威应用程序状态并只在适当的时候响应)，那么随时通知它们并相信它们会正确地响应就可以了。

处理程序不应该收到事件发生通知的唯一时间是事件实际上没有发生的时候!因此，如果你不想让一个处理程序得到通知，停止生成事件(即禁用控件或任何负责检测并在第一时间使事件存在的东西)。

Honestly, I think the Delegate class is unsalvageable. The merger/transition to a MulticastDelegate was a huge mistake, because it effectively changed the (useful) definition of an event from something that happens at a single instant in time, to something that happens over a timespan. Such a change requires a synchronization mechanism that can logically collapse it back into a single instant, but the MulticastDelegate lacks any such mechanism. Synchronization should encompass the entire timespan or instant the event takes place, so that once an application makes the synchronized decision to begin handling an event, it finishes handling it completely (transactionally). With the black box that is the MulticastDelegate/Delegate hybrid class, this is near impossible, so adhere to using a single-subscriber and/or implement your own kind of MulticastDelegate that has a synchronization handle that can be taken out while the handler chain is being used/modified. I'm recommending this, because the alternative would be to implement synchronization/transactional-integrity redundantly in all your handlers, which would be ridiculously/unnecessarily complex.

我看到很多人都倾向于用扩展的方法来做这件事……

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() );

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

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

但是，如果您正在制作一个公开事件的组件，则无法保证组件的使用者不会采用多线程，在这种情况下，您需要做好最坏的准备。

使用空委托确实解决了这个问题，但也会在每次调用事件时导致性能下降，并可能涉及GC。

您是对的，消费者试图取消订阅才会发生这种情况，但如果他们通过了临时副本，那么就认为消息已经在传输中。

如果你不使用临时变量，也不使用空委托，有人取消订阅，你会得到一个空引用异常，这是致命的，所以我认为代价是值得的。