开发人员可以通过多种方式被 .NET 中的无意资源泄漏所困扰。我认为将它们聚集在一个地方会很有用。
请为每个项目添加一个答案，以便获得最佳投票:)
问问题
984 次
17 回答
8
未能删除事件处理程序。
注册活动应与取消注册配对：
this.myObject.MyEvent += new EventHandler(myObject_MyEvent);
this.myObject.MyEvent -= new EventHandler(myObject_MyEvent);
有一个发生在CodeProject上的系统示例。
于 2009-05-29T16:09:02.270 回答
7
P/Invoking 到非托管代码，而不是清理它们，或者不实现 IDisposable 来清理它们。
于 2009-05-29T16:07:39.680 回答
7
不使用Using.
于 2009-05-29T17:10:55.210 回答
6
保持数据库连接打开。
于 2009-05-29T16:02:12.330 回答
4
未能实现 Dispose 并因此不释放子对象。
于 2009-05-29T16:04:12.487 回答
4
WCF 客户端对象不像其他 IDisposable 对象那样执行。如果操作处于错误状态，则必须中止 WCF 服务的客户端，否则它将保持连接打开。这通常是通过艰难的方式学习的。
于 2009-05-29T17:09:57.070 回答
2
使用 WeakReference 可能会导致细微的泄漏，其中 WeakReference 持有的对象被清理，因为它没有强引用，但 WeakReference 本身并不是因为你保持对它的强引用。
如果你有一个你从不修剪的弱引用列表或字典之类的东西，你可能会遇到这种情况。即使在收集了目标之后，您最终也会泄漏 WeakReference 对象。
于 2009-05-29T17:25:15.677 回答
2
几乎所有使用 Office API 的东西。由于它们都是 COM 对象，因此必须释放它们。如果要使用事件处理程序，还必须保留对它们的类引用，否则它们会丢失引用。在很多情况下，你甚至不得不手动调用 GC 来清理对象
于 2009-05-29T16:24:42.430 回答
2
容易内存泄漏：在 List 类型的类中创建一个静态字段。将项目添加到列表。它们永远不会被垃圾收集，所以除非你记得在完成它们时手动删除你的项目，否则内存会永远被占用。
于 2009-05-30T00:08:14.217 回答
1
未能在 System.Windows.Window 对象上调用“关闭”方法。
确保对 System.Windows.Window 对象的所有托管资源进行垃圾回收的唯一方法是调用 Window 对象的“Close()”方法。调用 Dispose 或将对象引用设置为 null 不会破坏对象。
于 2009-05-29T16:11:06.263 回答
1
在启动代码之外填充的静态列表、字典和基于集合的资源。
如果您将字典用作全局缓存而不是适当的基于 LRU 的缓存，则可能会发生这种情况。
任何静态的东西都需要格外小心！
于 2009-05-29T16:16:33.630 回答
1
如果您将托管内存视为“资源” - 未能取消挂钩事件处理程序是内存泄漏（以及各种其他更严重的错误）的常见来源。
于 2009-05-29T16:12:58.183 回答
0
未能在 .NET Compact Framework 上处理任何与绘图相关的对象（图形、字体、SolidBrush、笔等）。当您不想要时，这可能会导致一些严重的内存泄漏（移动设备 = 内存有限）。
于 2009-05-29T17:30:49.757 回答
0
模拟令牌句柄保持打开状态。
于 2009-05-29T16:06:49.680 回答
0
WPF 资源字典泄漏。一些有用的链接：
于 2009-11-26T12:15:55.240 回答
0
错误配置 Spring.NET 以创建应该是单例的东西的多个实例。
于 2009-11-26T12:20:48.643 回答
0
在Timer上调用 Dispose() 失败
于 2011-09-28T02:27:39.840 回答