我对内存泄漏的理解

CLR的垃圾回收器可以帮助我们回收资源，使得我们开发的时候不需要考虑对象回收，但是我们真的不用考虑了吗？

垃圾回收器明确说明其只会回收：

“不再使用的对象”

一、对内存泄漏的理解

我认为判断内存是否泄漏取决于你知不知情：

• 如果你清晰的知道对象引用关系，那么就不算内存泄漏，例如撤销重做栈（里面保存了大量的历史数据）。
• 如果你认为没有对象在引用这个对象了，而GC.Collect()执行后并没有回收这个对象，那么这就是内存泄漏。

导致内存泄漏的根本原因就是：

你以为对象已经用完了，但是仍有对象持有对它的引用

解决内存泄漏的根本措施就是：

当你的对象不需要的时候，不要让还活着的对象引用你

二、内存泄漏案例分析

下面我会列举我们开发过程中遇到的多种 “你认为没有人引用那个对象了” 的场景，场景会持续更新。

1. DispatcherTimer
2. Data Binding
3. Event Handler
4. Static Event

三、内存泄漏分析工具

分析内存泄漏的来龙去脉，不是一款工具就可以全部解决的，建议使用下面多个工具结合使用，可查源码，可调源码，可看堆栈，可看变量，非常的方便。使用教程请移步Google。
![内存泄漏分析工具.png]

image.png

1. dnSpy：附加进程调试神器，可以直接调试源码，不需要vs。
2. windbg：调试神器，方便的看托管堆的各种数据，牛刀。
3. dotPeek：查看托管Dll的源码，查看WPF的源码必备。
4. dotMemory：方便的对两个快照之间产生的对象进行跟踪，查看引用关系，方便的定位到内存泄漏现象。

以上工具结合使用，足矣让你掌握导致内存泄漏的最深层次的原因。