4

我不完全确定该去哪里寻求帮助，所以我想我会尝试使用 stackoverflow，因为它通常可以回答我大约 90% 的编程相关问题。

简而言之，我有一个正在泄漏内存的开源 .NET 应用程序。从某种意义上说，这可能不是真正的内存泄漏，当应用程序关闭时，我怀疑内存已被回收，但在它运行时，它会不断分配更多内存而不释放它。最终，aSystem.OutOfMemoryException被抛出。

为了调试问题，我按照本文中推荐的步骤进行了调试，并生成了下图，其中红色是 .NET/CLR 内存“#Bytes in all Heaps”，绿色是带有 Windows 性能监视器工具的进程“Private Bytes” （请注意，绿线已被统一缩小，看起来更接近红线，因为只有线条的形状对我来说很重要）：性能监视器输出。

我将图像作为托管内存泄漏的证据，然后使用 Windows 的调试诊断工具尝试定位泄漏源（如文章中所述）。然而，我从调试诊断工具得到的报告非常奇特。

基本上，每次尝试在应用程序运行时每 5 秒收集一次“完全 UserDump”，但由于当时垃圾收集器始终处于垃圾收集周期的中间，导致调试诊断输出错误并阻止它收集任何有用的 .NET 内存相关信息的工具。

现在我被卡住了，我知道我有一个托管的内存泄漏，但我不知道如何缩小它的范围。我也很困惑垃圾收集器如何总是处于收集周期的中间，这让我想知道垃圾收集线程是否被某种方式阻塞，阻止它释放内存和/或退出垃圾收集周期。

在性能监视器图的某些部分中，分配的 .NET 内存会下降一点，因此垃圾收集器不会永远卡住，但它肯定是大部分时间都卡住了，否则调试诊断应该能够做到一个用户转储。

几个问题：

  1. .NET 应用程序中的垃圾收集器是否有可能在尝试释放一些内存时卡住，可能来自一些编码不良的析构函数/终结器或其他东西？

  2. 我可以使用什么策略来继续缩小问题的根源？

4

1 回答 1

5

如果您提供.NET Framework 版本、操作系统版本、进程的位数和机器上的处理器数量，将会有所帮助。如果您很快收到内存不足异常，我会认为您正在运行 32 位进程，但如果您能确认，仍然会有所帮助。

首先，您应该通过查找进程的 GC 内存计数器中的%Time 来真正检查 GC 是否确实是问题的原因。您可以在 .NET CLR Memory 对象下的 PERFMON 中对此进行监控。如果这个计数器大于 30%，那么你肯定有 GC 问题。您粘贴的 PNG 并没有告诉我每秒分配了多少内存，所以如果它很高，那么 GC 会启动更多。

一个谨慎的词是使用最新的调试诊断工具来分析转储，看看你是否看到了不同的东西。DebugDiag 1.2 中存在一个问题，它可能导致错误地报告“垃圾收集中间”消息，因此您要确保 GC 在转储时确实在运行。您可以从http下载最新版本://www.microsoft.com/en-us/download/details.aspx?id=40336并使用该工具分析相同的转储文件，看看是否报告了不同的内容。同时在您的报告中搜索GarbageCollectionGeneration字符串，它将向您显示负责调用 GC 的线程。查看该线程的堆栈，您可能能够确定该线程正在做什么，最终调用了 GC。这可能有帮助，也可能没有帮助。

回答您的其他问题：-

1) 如果任何线程禁用了 PRE-EMPTIVE GC，GC 可能会卡住。您可以阅读文章http://blogs.msdn.com/b/tess/archive/2008/02/11/hang-caused-by-gc-xml-deadlock.aspx更多地了解 PRE-EMPTIVE GC 以及如何找出禁用了抢先 GC 的线程。

2）我会在 WinDBG 中打开转储，然后按照上面博客中提到的方法查看是否到达某个地方。如果框架是 .net 框架 4.0 或更高版本，您还可以使用 PERFVIEW 工具收集跟踪信息，并提供有关 GC 发生原因的良好信息。在http://channel9.msdn.com/Series/PerfView-Tutorial/PerfView-Tutorial-9-NET-Memory-Investigation-Basics-of-GC-Heap-Snapshots查看 PERFVIEW 的视频以解决 GC 问题

此外，如果这个 EXE 正在做一些后台处理，您可能需要启用 GC 的服务器模式，看看是否有帮助。阅读文章http://blogs.msdn.com/b/clyon/archive/2004/09/08/226981.aspx了解更多信息。

希望这可以帮助 ！！！

于 2014-01-24T05:32:27.790 回答