小编给大家分享一下C#中event内存泄漏的示例分析，相信大部分人都还不怎么了解，因此分享这篇文章给大家参考一下，希望大家阅读完这篇文章后大有收获，下面让我们一起去了解一下吧！
内存泄漏示例
为了演示内存泄漏是如何发生的，我们来看一段代码
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，可以看到
IL_0000: nop IL_0001: newobj instance void EventLeakMemory.Program/TestAction::.ctor() IL_0006: stloc.0 IL_0007: ldloc.0 IL_0008: ldftn instance void EventLeakMemory.Program/TestAction::Run() IL_000e: newobj instance void [mscorlib]System.Action::.ctor(object, native int) IL_0013: call void EventLeakMemory.Program::add_TestEvent(class [mscorlib]System.Action)...//其他部分
关键在5-7行。第5和6行，声明了一个System.Action型的委托，参数为TestAction.Run方法，第七行，执行了Program.add_TestEvent方法，参数是上面声明的委托。也就是说+=操作符相当于执行了Add_TestEvent（new Action(memory.Run)），就是这个new Action包含了对memory指向的内存的引用。而这个引用在CLR看来是可达的，可以通过引发事件来调用该内存。
解决办法
我们已经找到了内存泄漏的元凶，就是订阅事件时，隐式声明的匿名委托对内存的引用。该问题的解决办法是使用一种和普通的引用不同的方式来引用方法的实例对象：该引用不会影响垃圾回收，不会在GC时被判定为对该内存的引用，也就是“弱引用”。C#中，绝大部分的类型都是强引用。如何实现弱引用？来看一个例子：
static void Main(string[] args){
var obj = new object();
var gcHandle = GCHandle.Alloc(obj, GCHandleType.Weak);
Console.WriteLine("gcHandle.Target == null is :{0}", gcHandle.Target == null);
obj = null;
GC.Collect();
Console.WriteLine("GC.Collect");
Console.WriteLine("gcHandle.Target == null is :{0}", gcHandle.Target == null);
Console.ReadLine();
}当执行GC。Collect后，gcHandle.Target == null 由false 变成了true。这个gcHandle就是obj的一个弱引用。这个类的详细介绍见 GCHandle 。比较关键的是GCHandle.Alloc方法的第二个参数，该参数接受一个枚举类型。我使用的是GCHandleType.Weak，表明该引用是个弱引用。利用这个方法，就可以封装一个自己的WeakReference类，代码如下
public class WeakReferencewhere T : class { private GCHandle handle; public WeakReference(T obj) { if (obj == null) return; handle = GCHandle.Alloc(obj, GCHandleType.Weak); } /// /// 引用的目标是否还存活(没有被GC回收) /// public bool IsAlive { get { if (handle == default(GCHandle)) return false; return handle.Target != null; } } ////// 引用的目标 /// public T Target { get { if (handle == default(GCHandle)) return null; return (T)handle.Target; } } }
利用该类，就可以写一个自己的弱事件封装器。