开发人员可能会因 .NET 中的无意资源泄漏而陷入困境。我认为将它们收集在一个地方会很有用。
请为每个项目添加一个答案，以便选出最好的：)
【问题讨论】：
标签： .net memory memory-leaks resource-leak
未能删除事件处理程序。
注册活动应与取消注册配对：
this.myObject.MyEvent += new EventHandler(myObject_MyEvent);
this.myObject.MyEvent -= new EventHandler(myObject_MyEvent);
有一个发生在CodeProject 上的系统示例。
【讨论】：
P/调用非托管代码，不清理它们，或者不实现 IDisposable 来清理它们。
【讨论】：
不使用Using。
【讨论】：
保持数据库连接打开。
【讨论】：
未能实现 Dispose，因此不释放子对象。
【讨论】：
WCF 客户端对象的性能与其他 IDisposable 对象不同。如果操作处于错误状态，则必须中止 WCF 服务的客户端，否则它将保持连接打开。这通常是很难学会的。
【讨论】：
几乎所有使用 Office API 的东西。由于它们都是 COM 对象，因此必须释放它们。如果要使用事件处理程序，还必须保留对它们的类引用，否则它们会失去引用。在很多情况下，你甚至不得不手动调用 GC 来清理对象
【讨论】：
使用 WeakReference 可能会导致微妙的泄漏，其中 WeakReference 持有的对象被清除，因为它没有强引用，但 WeakReference 本身并不是因为您保留对它的强引用。
如果你有一个你从不修剪的弱引用列表或字典之类的东西，你可能会遇到这种情况。即使目标已被收集，您最终也会泄漏 WeakReference 对象。
【讨论】：
容易的内存泄漏：在 List 类型的类中创建一个静态字段。将项目添加到列表。它们永远不会被垃圾收集，所以除非你记得在完成它们后手动删除你的项目，否则内存会永远被占用。
【讨论】：
未能在 System.Windows.Window 对象上调用“关闭”方法。
确保 System.Windows.Window 对象的所有托管资源都被垃圾回收的唯一方法是调用 Window 对象的“Close()”方法。调用 Dispose 或将对象引用设置为 null 不会破坏对象。
【讨论】：
如果您将托管内存视为“资源” - 未能取消挂钩事件处理程序是内存泄漏（以及各种其他更严重的错误）的常见来源。
【讨论】：
在启动代码之外填充的静态列表、字典和基于集合的资源。
如果您将字典用作全局缓存而不是适当的基于 LRU 的缓存，则可能会发生这种情况。
任何静态都需要格外小心！
【讨论】：
模拟令牌句柄保持打开状态。
【讨论】：
未能在 .NET Compact Framework 上处理任何与绘图相关的对象（图形、字体、SolidBrush、钢笔等）。这可能会在您不希望的情况下导致一些严重的内存泄漏（移动设备 = 内存有限）。
【讨论】：
错误配置 Spring.NET 以创建应该是单例的东西的多个实例。
【讨论】：
调用 Timer 上的 Dispose() 失败
【讨论】：