内存消耗增加并不一定表示资源泄漏，因为垃圾收集是非确定性的，可能尚未启动。 即使您“放开”对象，只要CLR认为系统上有足够的资源，CLR就可以自由地保留它们。

如果您确实知道您确实存在资源泄漏，那么您可以使用具有显式Close / Dispose作为其合同一部分的对象（用于“使用…”构造）。 在这种情况下，如果您可以控制类型，则可以在Dispose实现中标记对象的处理，以validation它们实际上是否已被处置，如果您可以将生命周期管理泄漏到类型的界面中。

如果您执行后者，则可以对合同处置进行unit testing。 我在某些情况下使用特定于IDisposable的应用程序（扩展该接口），添加了用于查询对象是否已被处置的选项。 如果在类型上显式实现该接口，则不会对其接口造成太多污染。

如果您无法控制相关类型，则可以使用其他地方建议的内存分析器。 （例如Jetbrains的dotTrace 。）

您不需要需要内存分析器的unit testing。 您可以从CLR Profiler开始。

当托管类型在没有适当注意的情况下使用非托管资源时，通常会引入内存泄漏。

一个典型的例子是System.Threading.Timer ，它将回调方法作为参数。 因为计时器最终使用非托管资源，所以引入了新的GC根，只能通过调用计时器的Dispose方法来释放。 在这种情况下，您的类型也应该实现IDisposable否则此对象永远不会被垃圾收集（泄漏）。

您可以通过执行与此类似的操作为此方案编写unit testing：

  var instance = new MyType(); // ... // Use your instance in all the ways that may trigger creation of new GC roots // ... var weakRef = new WeakReference(instance); instance.Dispose(); instance = null; GC.Collect(); GC.WaitForPendingFinalizers(); GC.Collect(); Assert.IsFalse(weakRef.IsAlive); 

dotMemory Unit框架具有以编程方式检查分配的某些对象的数量，内存流量，制作和比较内存快照的function。

您可能可以挂钩到分析API，但看起来您必须在启用分析器的情况下启动unit testing。

如何创建对象？ 直接或某种可以控制的方式。 如果可控制返回带有终结器的扩展版本，这些终结器注册它们已经被丢弃。 然后

 GC.Collect(); GC.WaitForPendingFinalizers(); Assert.IsTrue(HasAllOfTypeXBeenFinalized()); 

怎么样的：

上述就是C#学习教程：unit testing内存泄漏分享的全部内容，如果对大家有所用处且需要了解更多关于C#学习教程，希望大家多多关注—计算机技术网(www.ctvol.com)!

 long originalByteCount = GC.GetTotalMemory(true); SomeOperationThatMayLeakMemory(); long finalByteCount = GC.GetTotalMemory(true); Assert.AreEqual(originalByteCount, finalByteCount);