编辑：在Joel Coehoorns的优秀答案之后，我明白我需要更加具体，所以我修改了我的代码，使其更贴近我正在努力理解的事情......
事件：据我所知，事件背景中的事件是EventHandlers的“集合”，即代表，将在事件引发时执行。所以对我而言，这意味着如果对象 Y 有事件E而对象X订阅事件 YE ，那么 Y 将引用X，因为 Y 必须执行位于X中的方法，这样就无法收集 X ，这是我理解的。
//Creates reference to this (b) in a.
a.EventHappened += new EventHandler(this.HandleEvent);
但这不是Joel Coehoorn所说的......
但是，事件存在问题，有时人们喜欢将IDisposable与具有事件的类型一起使用。问题是当类型X订阅另一个类型Y的事件时，X现在有一个对Y的引用。这个引用将阻止Y被收集。
我不明白 X 将如何引用Y ???
我修改了一些我的例子，以更接近地说明我的情况：
class Service //Let's say it's windows service that must be 24/7 online
{
A _a;
void Start()
{
CustomNotificationSystem.OnEventRaised += new EventHandler(CustomNotificationSystemHandler)
_a = new A();
B b1 = new B(_a);
B b2 = new B(_a);
C c1 = new C(_a);
C c2 = new C(_a);
}
void CustomNotificationSystemHandler(args)
{
//_a.Dispose(); ADDED BY **EDIT 2***
a.Dispose();
_a = new A();
/*
b1,b2,c1,c2 will continue to exists as is, and I know they will now subscribed
to previous instance of _a, and it's OK by me, BUT in that example, now, nobody
references the previous instance of _a (b not holds reference to _a) and by my
theory, previous instance of _a, now may be collected...or I'm missing
something???
*/
}
}
class A : IDisposable
{
public event EventHandler EventHappened;
}
class B
{
public B(A a) //Class B does not stores reference to a internally.
{
a.EventHappened += new EventHandler(this.HandleEventB);
}
public void HandleEventB(object sender, EventArgs args)
{
}
}
class C
{
public C(A a) //Class B not stores reference to a internally.
{
a.EventHappened += new EventHandler(this.HandleEventC);
}
public void HandleEventC(object sender, EventArgs args)
{
}
}
编辑2：好的，现在很清楚，当订阅者订阅发布商事件时， NOT 会在订阅者中创建对发布者的引用。只有从发布者到订阅者的引用创建（通过EventHandler）...在这种情况下，当发布者在订阅者之前收集发布者（订阅者的生命周期大于发布者）时，没有问题。
但是 ......据我所知，当GC收集发布商时，并不能保证理论上，即使订阅者的生命周期比出版商更大，也可能发生订阅者合法收集，但仍然没有收集发布者（我不知道在最接近的GC周期内，GC是否足够智能，先收集发布者然后收集订阅者。
无论如何，在这种情况下，由于我的订阅者没有直接引用发布者并且无法取消订阅该事件，我想让发布者实现IDisposable，以便在删除所有引用之前将其处理掉（参见在我的示例中的CustomNotificationSystemHandler中。
AND AGAIN 我应该在publishers dispose方法中写什么来清除对订阅者的所有引用？应该是EventHappened - = null;或EventHappened = null;或者没有办法以这种方式做到，我需要做下面的事情???
public event EventHandler EventHappened
{
add
{
eventTable["EventHappened"] = (EventHandler)eventTable["EventHappened"] + value;
}
remove
{
eventTable["EventHappened"] = (EventHandler)eventTable["EventHappened"] - value;
}
}
答案 0 :(得分：13)
物体B的寿命比A长，所以A可以提前放置
听起来你在混淆“处理”与“收藏”？处置对象与内存或垃圾回收有无。为了确保一切都清楚，让我们分解两个场景，然后我将继续讨论最后的事件：
<强>收集：
没什么你会在它的父B之前收集A。只要B 可以到达，A也是如此。即使A是私有的，它也是仍然可以从B内的任何代码到达，因此只要B可以到达，A就被认为是可达的。这意味着垃圾收集器不确定您是否完成了它，并且在收集B之前永远不会收集A.即使您明确调用GC.Collect（）或类似的东西也是如此。只要对象可以访问，就不会收集它。
<强>处理：
我甚至不确定你为什么在这里实现IDisposable（它没有没有与内存或垃圾收集有关），但我会给你带来怀疑的好处我们只是看不到非托管资源。
没有什么可以阻止您随时处置A。只需调用a.Dispose（），就完成了。 .Net框架将自动为您调用Dispose（）的唯一方法是using块结束。在垃圾收集期间不会调用Dispose（），除非您将其作为对象的终结器的一部分（稍后更多关于终结器）。
当实现IDisposable时，您正在向程序员发送一条消息，即此类型应该（甚至可能“必须”）立即处理。任何IDisposable对象都有两种正确的模式（模式有两种变体）。第一种模式是将类型本身封装在一个使用块中。当这是不可能的时（例如：类型是其他类型的成员的代码），第二种模式是父类型也应该实现IDisposable，因此它本身可以包含在一个使用块中，它是Dispose（）可以调用你的类型的Dispose（）。这些模式的变化是使用try / finally块而不是using块，在finally块中调用Dispose（）。
现在进入终结者。您需要实现终结器的唯一时间是发起非托管资源的IDisposable类型。因此，例如，如果上面的类型A只是包装类似SqlConnection的类，则它不需要终结器，因为SqlConnection本身的终结器将负责任何所需的清理。但是，如果您的类型A实现了与全新数据库引擎的连接，那么您需要一个终结器，以便确保在收集对象时关闭您的连接。但是，类型B不需要终结器，即使它管理/包装您的类型A，因为类型A将负责完成连接。
<强>活动：
从技术上讲，事件仍然是托管代码，不需要处理。但是，事件存在问题，有时人们喜欢将IDisposable与具有事件的类型一起使用。问题是，当类型X订阅另一个类型Y的事件时，Y现在具有对X的引用。该引用可以防止收集X.如果你期望Y的生命周期比X长，你可以在这里遇到问题，特别是如果Y相对于随时间变化的许多X来说是非常长寿的。
为了解决这个问题，有时程序员将使用Y类实现IDisposable，而Dispose（）方法的目的是取消订阅任何事件，以便也可以收集订阅对象。从技术上讲，这不是Dispose（）模式的目的，但它运作良好，我不会争论它。将此模式与事件一起使用时，您需要了解两件事：
在这种情况下，您的类型A对于类型B是私有的，因此只有类型B可以订阅A的事件。由于'a'是B类的成员，因此在B不再可达之前，它们都不符合垃圾收集条件，此时两者将不再可访问，并且事件订阅引用将不计算。这意味着A事件在B上持有的引用不会阻止B被收集。但是，如果您在其他地方使用A类型，您可能仍希望具有A实现IDisposable以确保您的事件已取消订阅。如果这样做，请确保遵循整个模式，以便A的实例包含在using或try / finally块中。
答案 1 :(得分：4)
我在示例代码中添加了我的评论。
class A : IDisposable
{
public event EventHandler EventHappened
{
add
{
eventTable["EventHappened"] = (EventHandler)eventTable["EventHappened"] + value;
}
remove
{
eventTable["EventHappened"] = (EventHandler)eventTable["EventHappened"] - value;
}
}
public void Dispose()
{
//Amit: If you have only one event 'EventHappened',
//you can clear up the subscribers as follows
eventTable["EventHappened"] = null;
//Amit: EventHappened = null will not work here as it is
//just a syntactical sugar to clear the compiler generated backing delegate.
//Since you have added 'add' and 'remove' there is no compiler generated
//delegate to clear
//
//Above was just to explain the concept.
//If eventTable is a dictionary of EventHandlers
//You can simply call 'clear' on it.
//This will work even if there are more events like EventHappened
}
}
class B
{
public B(A a)
{
a.EventHappened += new EventHandler(this.HandleEventB);
//You are absolutely right here.
//class B does not store any reference to A
//Subscribing an event does not add any reference to publisher
//Here all you are doing is calling 'Add' method of 'EventHappened'
//passing it a delegate which holds a reference to B.
//Hence there is a path from A to B but not reverse.
}
public void HandleEventB(object sender, EventArgs args)
{
}
}
class C
{
public C(A a)
{
a.EventHappened += new EventHandler(this.HandleEventC);
}
public void HandleEventC(object sender, EventArgs args)
{
}
}
class Service
{
A _a;
void Start()
{
CustomNotificationSystem.OnEventRaised += new EventHandler(CustomNotificationSystemHandler)
_a = new A();
//Amit:You are right all these do not store any reference to _a
B b1 = new B(_a);
B b2 = new B(_a);
C c1 = new C(_a);
C c2 = new C(_a);
}
void CustomNotificationSystemHandler(args)
{
//Amit: You decide that _a has lived its life and must be disposed.
//Here I assume you want to dispose so that it stops firing its events
//More on this later
_a.Dispose();
//Amit: Now _a points to a brand new A and hence previous instance
//is eligible for collection since there are no active references to
//previous _a now
_a = new A();
}
}
b1，b2，c1，c2将继续存在，我知道他们现在会 订阅了以前的_a实例，我也没关系，但是那个 例如，现在，没有人引用前一个_a实例（b不是 暂时引用_a）和我的理论，现在是_a的前一个实例 可能会被收集......或者我错过了什么？
正如我在上面的代码中的评论所解释的那样，你在这里没有遗漏任何东西：）
但是......据我所知，当GC收集时，并不能保证 因此，理论上，即使订阅者的生命周期大于此 出版商，可能会发生订户合法收集，但 发布者仍未收集（我不知道是否在最近的GC内 循环，GC将足够聪明，先收集出版商 订户。
由于发布者引用订阅者，订阅者在发布者之前就没有资格收集，但反向可能是真的。如果发布者在订阅者之前收集，那么正如您所说，没有问题。如果订阅者属于比发布者更低的GC代，那么由于发布者持有对订阅者的引用，因此GC会将订阅者视为可达，并且不会收集订阅者。如果两者都属于同一代人，他们将被收集在一起。
因为我的订阅者没有直接引用发布者和 无法取消订阅活动，我想让出版商来 实现IDisposable
与某些人提出的建议相反，如果在任何时候您确定不再需要该对象，我建议实施dispose。简单地更新对象引用可能并不总是导致对象停止发布事件。
请考虑以下代码：
class MainClass
{
public static Publisher Publisher;
static void Main()
{
Publisher = new Publisher();
Thread eventThread = new Thread(DoWork);
eventThread.Start();
Publisher.StartPublishing(); //Keep on firing events
}
static void DoWork()
{
var subscriber = new Subscriber();
subscriber = null;
//Subscriber is referenced by publisher's SomeEvent only
Thread.Sleep(200);
//We have waited enough, we don't require the Publisher now
Publisher = null;
GC.Collect();
//Even after GC.Collect, publisher is not collected even when we have set Publisher to null
//This is because 'StartPublishing' method is under execution at this point of time
//which means it is implicitly reachable from Main Thread's stack (through 'this' pointer)
//This also means that subscriber remain alive
//Even when we intended the Publisher to stop publishing, it will keep firing events due to somewhat 'hidden' reference to it from Main Thread!!!!
}
}
internal class Publisher
{
public void StartPublishing()
{
Thread.Sleep(100);
InvokeSomeEvent(null);
Thread.Sleep(100);
InvokeSomeEvent(null);
Thread.Sleep(100);
InvokeSomeEvent(null);
Thread.Sleep(100);
InvokeSomeEvent(null);
}
public event EventHandler SomeEvent;
public void InvokeSomeEvent(object e)
{
EventHandler handler = SomeEvent;
if (handler != null)
{
handler(this, null);
}
}
~Publisher()
{
Console.WriteLine("I am never Printed");
}
}
internal class Subscriber
{
public Subscriber()
{
if(MainClass.Publisher != null)
{
MainClass.Publisher.SomeEvent += PublisherSomeEvent;
}
}
void PublisherSomeEvent(object sender, EventArgs e)
{
if (MainClass.Publisher == null)
{
//How can null fire an event!!! Raise Exception
throw new Exception("Booooooooommmm");
//But notice 'sender' is not null
}
}
}
如果您运行上述代码，通常会收到“Booooooooommmm”。因此，当我们确定它的生命已经结束时，事件发布者必须停止发射事件。
这可以通过Dispose方法完成。
有两种方法可以实现这一目标：
2的好处是你释放对订阅者的任何引用，从而实现了收集（正如我之前解释的那样，即使发布者是垃圾但属于更高代，那么它仍然可以延长较低代订阅者的收集）。 p>
但是，诚然，由于出版商的“隐藏”可达性，您很少会体验到所表现出的行为，但您可以看到2的好处是明确的，并且适用于所有活动出版商，特别是长期出生的人（单身人士）任何人！）。这本身就值得实现Dispose并使用2。
答案 2 :(得分：3)
与其他答案所声称的相反，发布商的GC生命周期可能超过订阅者的使用寿命的事件应被视为非托管资源。短语“非托管资源”中的术语“非托管”并不意味着“完全在托管代码世界之外”，而是指对象是否需要超出托管垃圾收集器提供的清理。
例如，集合可能会公开CollectionChanged事件。如果重复创建和放弃订阅这样的事件的某些其他类型的对象，则该集合可能最终持有对每个这样的对象的委托引用。如果发生这样的创造和放弃，例如每秒一次（如果有问题的对象是在更新UI窗口的例程中创建的话，可能会发生这种情况），这些引用的数量可能会超过程序运行的每天86,000。对于一个从未运行超过几分钟的程序来说，这不是一个大问题，但对于一个可以一次运行数周的程序来说绝对是杀手锏。
微软在vb.net或C＃中没有提出更好的事件清理模式真的很不幸。订阅事件的类实例在放弃它之前不应该清理它们很少有任何理由，但微软没有采取任何措施来促进这种清理。在实践中，人们可以放弃放弃经常订阅事件的对象（因为事件发布者将在与订阅者大约同一时间内超出范围），确保事件得到适当清理所需的烦人程度的努力不会看起来不值得。不幸的是，预测事件发布者可能比预期寿命更长的所有情况并不总是那么容易;如果许多类使事件悬空，那么大量内存可能无法收集，因为其中一个事件订阅碰巧属于一个长期存在的对象。
响应编辑的附录
如果X订阅Y中的某个活动，然后放弃对Y的所有引用，并且Y符合收集资格，X不会阻止Y被收集。那将是一件好事。如果X要强制引用Y以便能够处理它，则此类引用会阻止Y被收集。这可能说不是一件好事。在某些情况下，X最好将长WeakReference（第二个参数设置为true）构建为Y而不是直接引用;如果在WeakReference为X d时Dispose的目标为非空，则必须取消订阅Y的事件。如果目标为空，则无法取消订阅但无关紧要，因为到那时Y（及其对X的引用）将完全不复存在。请注意，在Y死亡并复活的不太可能的情况下，X仍然希望取消订阅其活动;使用长WeakReference将确保仍然可以发生。
虽然有些人认为X不应该费心保留对Y的引用，而Y应该只是编写使用某种弱事件调度，这样的行为不是在一般情况下是正确的，因为Y无法判断X是否会执行其他代码可能关心的任何内容，即使Y仅包含对{{1}的引用}} 的。 X完全可能包含对某个强根对象的引用，并且可能对其事件处理程序中的其他对象执行某些操作。 X仅保留Y的唯一引用这一事实并不意味着X中没有其他对象“感兴趣”。唯一通常正确的解决方案是让不再对其他对象事件感兴趣的对象通知后一个对象。
答案 3 :(得分：1)
我会让我的B类实现IDisposable，并且在它的dispose例程中，我首先检查A是否为null然后处理A.通过使用这种方法，你必须确保处理你的最后一个类并且内部人员将处理所有其他处置。
答案 4 :(得分：0)
在处置对象时， 。我的意思是，GC会清理事件处理程序，而不需要您进行任何干预，但是根据情况，您可能希望在GC之前删除这些事件处理程序，以防止在您执行时调用处理程序。期待它。
在您的示例中，我认为您的角色已被颠倒 - 类A不应该取消订阅其他人添加的事件处理程序，并且不需要删除事件处理程序，因为它可以反而只是停止提升那些事件！
假设情况正好相反
class A
{
public EventHandler EventHappened;
}
class B : IDisposable
{
A _a;
private bool disposed;
public B(A a)
{
_a = a;
a.EventHappened += this.HandleEvent;
}
public void Dispose(bool disposing)
{
// As an aside - if disposing is false then we are being called during
// finalization and so cannot safely reference _a as it may have already
// been GCd
// In this situation we dont to remove the handler anyway as its about
// to be cleaned up by the GC anyway
if (disposing)
{
// You may wish to unsubscribe from events here
_a.EventHappened -= this.HandleEvent;
disposed = true;
}
}
public void HandleEvent(object sender, EventArgs args)
{
if (disposed)
{
throw new ObjectDisposedException();
}
}
}
如果A处理B后，B可能继续引发事件，B的事件处理程序可能会导致异常或其他意外事件行为{{1}}如果被处置，那么首先取消订阅此事件可能是一个好主意。
答案 5 :(得分：0)
“为了防止在引发事件时调用事件处理程序，请取消订阅事件。为了防止资源泄漏，您应该在处置订阅者对象之前取消订阅事件。在您取消订阅事件之前，发布对象中作为事件基础的多播委托具有对封装订阅者事件处理程序的委托的引用。只要发布对象保存该引用，垃圾收集就不会删除您的订阅者对象。“
“当所有订阅者都取消订阅某个事件时，发布商类中的事件实例将设置为null。”
答案 6 :(得分：0)
对象A通过EventHandler委托引用B（A有一个引用B的EventHandler实例）。 B没有任何对A的引用。当A被设置为null时，它将被收集并释放内存。 所以在这种情况下你不需要清除任何东西。