C#中event内存泄漏总结

内存泄漏是指：当一块内存被分配后，被丢弃，没有任何实例指针指向这块内存， 并且这块内存不会被GC视为垃圾进行回收。这块内存会一直存在，直到程序退出。C#是托管型代码，其内存的分配和释放都是由CLR负责，当一块内存没有任何实例引用时，GC会负责将其回收。既然没有任何实例引用的内存会被GC回收，那么内存泄漏是如何发生的？

内存泄漏示例

为了演示内存泄漏是如何发生的，我们来看一段代码

class Program { static event Action TestEvent; static void Main(string[] args) {  var memory = new TestAction();  TestEvent += memory.Run;  OnTestEvent();  memory = null;  //强制垃圾回收  GC.Collect(GC.MaxGeneration);  Console.WriteLine("GC.Collect");  //测试是否回收成功  OnTestEvent();  Console.ReadLine(); } public static void OnTestEvent() {  if (TestEvent != null) TestEvent();  else Console.WriteLine("Test Event is null"); } class TestAction  {  public void Run() {   Console.WriteLine("TestAction Run.");  } }}

该例子中，memory.run订阅了TestEvent事件，引发事件后，会在屏幕上看到 TestAction Run。当memory =null 后，memory原来指向的内存就没有任何实例再引用该块内存了，这样的内存就是待回收的内存。GC.Collect(GC.MaxGeneration)语句会强制执行一次垃圾回收，再次引发事件，发现屏幕上还是会显示TestAction Run。该内存没有被GC回收，这就是内纯泄漏。这是由TestEvent+=memory.Run语句引起的，当GC.Collect执行的时候，当他看到该块内存还有TestEvent引用，就不会进行回收。但是该内存已经是“无法到达”的了，即无法调用该块内存，只有在引发事件的时候，才能执行该内存的Run方法。这显然不是我想要的效果，当memory = null执行时，我希望该内存在GC执行时被回收，并且当TestEvent被引发时，Run方法不会执行，因为我已经把该内存“解放”了。

这里有一个问题，就是C#中如何“释放”一块内存。像C和C++这样的语言，内存的声明和释放都是开发人员负责的，一旦内存new了出来，就要delete，不然就会造成内存泄漏。这更灵活，也更麻烦，一不小心就会泄漏，忘记释放、线程异常而没有执行释放的代码...有手动分配内存的语言就有自动分配和释放的语言。最开始使用垃圾回收的语言是LISP，之后被用在Java和C#等托管语言中。像C#，CLR负责内存的释放，当程序执行一段时间后，CLR检测到垃圾内存已经值得进行一次垃圾回收时，会执行垃圾回收。至于如何判定一块内存是否为垃圾内存，比较著名的是计数法，即有一个实例引用了该内存后，就在该内存的计数上+1，改实例取消了对该内存的引用，计数就-1，当计数为0时，就被判定为垃圾。该种方法的问题是对循环引用束手无策，如A的某个字段引用了B，而B的某个字段引用了A，这样A和B的技术都不会降到0。CLR改用的方法是类似“标记引用法”（我自己的命名）：在执行GC时，会挂起全部线程，并将托管堆中所有的内存都打上垃圾的标记，之后遍历所有可到达的实例，这些实例如果引用了托管堆的内存，就将该内存的标记由垃圾变为被引用。当遇到A和B相互引用的时候，如果没有其他实例引用A或者B，虽然A和B相互引用，但是A和B都是不可到达的，即没办法引用A或者B，则A和B都会被判定为垃圾而被回收。讲解了这么一大堆，目的就是要说，在C#中，你想要释放一块内存，你只要让该块内存没有任何实例引用他，就可以了。那么当执行memory = null后，除了对TestEvent的订阅，没有任何实例再引用了该块内存，那么为什么订阅事件会阻止内存的释放？

我们来看看TestEvent+=memory.Run()这句话都干了什么。我们利用IL反编译上面的dll，可以看到