为什么默认情况下C＃中事件的实现不会使用弱事件模式？ [英] Why is the implementation of events in C# not using a weak event pattern by default?

问题描述

这个问题可能导致投机答案，但我认为在事件 23class =post-tagtitle =show questions tagged'c＃'rel =tag> c＃。

This question may lead to speculative answers but I presume there's a well thought design decision behind the implementation of event in c#.

c＃保持订阅者活着只要活动的出版者还活着。因此，如果你不取消订阅，你会泄漏记忆（好吧，没有真正泄露 - 但记忆不必要地被占用）。

The event pattern in c# keeps the subscriber alive as long as the publisher of the event is alive. Thus, if you don't unsubscribe, you're leaking memory (well, not really leaking - but memory remains occupied unnecessarily).

如果我想防止这一点，我可以取消订阅活动或实施弱活动模式作为在MSDN上提出。

If I want to prevent this, I can unsubscribe from events or implement a weak event pattern as proposed at MSDN.

由于事件模式引起了如此多的问题（对于初学者？），问题是：为什么决定发布者对订阅者有很强的引用，而不是让他们独立或允许开发人员明确地拥有一个 strong 或 weak 修饰符

With the event pattern causing so many problems (for beginners?), the question is: why was the decision made that the publisher keeps a strong reference to the subscriber, instead of making them independent or allowing developers to explicitly have a strong or weak modifier?

已经有几个问题在这里关于这个主题和答案听起来合理，但没有一个真正的答案为什么它是这样的。

There are already a couple of questions here about this topic and the answers sound reasonable, but none really answers why it is like it is.

推荐答案

一个原因肯定是性能。 GC处理（它为所有异国情调引用（例如 WeakReference ）提供功能）带来性能成本。弱事件比强事件慢，因为它们需要GC句柄。强大的事件（默认情况下）由存储代理的实例字段实现。这只是一个普通的管理参考，便宜于任何其他参考。

One reason certainly is performance. GC handles (which power all of the "exotic" references such as WeakReference) come with a performance cost. Weak events are slower than "strong" events since they require a GC handle. A strong event is implemented (by default) by an instance field storing a delegate. This is just an ordinary managed reference as cheap as any other reference.

事件应该是一个非常通用的机制。它们不仅适用于您可能有几十个事件处理程序的UI方案。在这样一个基本的语言功能中，要花费很多复杂性和性能成本是不明智的。

Events are supposed to be a very general mechanism. They are not just meant for UI scenarios in which you have maybe a few dozen event handlers. It is not a wise idea to bake a lot of complexity and performance cost into such a basic language feature.

还有一个语义差异和非确定性，这将导致弱引用。如果你连接（）=>对于某些事件，LaunchMissiles（）可能会发现有时会发射导弹。其他时候，GC已经把处理程序拿走了。这可以通过依赖句柄引入另一个复杂程度。

There also is a semantic difference and non-determinism that would be caused by weak references. If you hook up () => LaunchMissiles() to some event you might find the missiles to be launched just sometimes. Other times the GC has already taken away the handler. This could be solved with dependent handles which introduce yet another level of complexity.

请注意，您可以透明地向订阅者实施弱事件。事件就像属性一样，它们仅仅是元数据和基于添加和删除访问器方法的约定。所以这是（只是）关于.NET语言选择的默认值的问题。这不是CLR的设计问题。

Note, that you can implement weak events yourself transparently to the subscriber. Events are like properties in the sense that they are mere metadata and conventions based around the add and remove accessor methods. So this is (just) a question about the defaults that the .NET languages chose. This is not a design question of the CLR.

我个人觉得很少有事件的强参考性质是一个问题。通常情况下，在相同或非常相似的生命周期的对象之间挂起事件。例如，您可以在ASP.NET中的HTTP请求的上下文中连接所有您想要的事件，因为当请求已经结束时，所有将有资格收集。任何泄漏都有大小和短暂的限制。

I personally find it rare that the strong referencing nature of events is a problem. Often, events are hooked up between objects that have the same or very similar lifetime. For example you can hook up events all you want in the context of an HTTP request in ASP.NET because everything will be eligible for collection when the request has ended. Any leaks are bounded in size and short lived.

这篇关于为什么默认情况下C＃中事件的实现不会使用弱事件模式？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！