.NET 3.5 Windows 服务的 GC 句柄数 (#) 不断增长的根本原因是什么？

Question

我有一个在 .NET Framework 3.5 上运行的 C# Windows 服务，该服务显示出不断增长的 GC 句柄数量（使用 Windows Server 2003 上的系统监视器可以看到）。

我已确保所有资源都得到正确处理，并且我的代码中没有终结器。

“大对象堆大小”和“所有堆中的字节数”相对静态，我可以看到“GC 中的％时间”显示正在发生垃圾收集。

“私有字节”计数器也在增加。

此症状导致任务管理器中的“内存使用量”每天增长约 35 MB，这是不可接受的，因为该服务基本上是针对 Oracle 10g 运行一个简单的 SELECT 查询，并每 5 秒使用 .NET TraceSources。 可能值得一提的是，TraceSource 使用 .NET Listeners 对象输出到 Windows 事件日志和文本文件。

有谁知道为什么“# GC Handles”不断增加，因为我相信这与我的“内存使用量”增加有关？

Answer 1

好的 - 排序了。

检查 .NET TraceSource 类的源代码后，发现根据设计，它拥有 2 个 WeakReferences 列表 - 1 个用于 TraceSource 对象，另一个用于 Switches。

它这样做是为了支持其 RefreshAll 方法。

我必须使用反射来手动清除这些列表。 所以，我不能再安全地使用 RefreshAll 方法，但至少我不再有 Private Bytes 和 GC Handles 的增长。

要重现该问题，只需创建整个 TraceSource 对象负载并关闭它们 - 您可以看到“泄漏”。

Answer 2

您没有释放代码正确引用的非托管资源。

您熟悉固定语句吗？ 它可以固定内存，以便以不安全的方式对其进行访问。 然而，还有另一种方法可以做到这一点，我们认为这种方法可能不安全。

var handle = System.Runtime.InteropServices.GCHandle.Alloc(myObject,
        System.Runtime.InteropServices.GCHandleType.Pinned);

上述类型的代码正是可能导致您的问题类型的原因。 如果您没有显式地“.Free()”此固定内存，您将不会最终对该对象进行垃圾收集，并且会出现内存泄漏。

我的猜测是，类似的事情也发生在您的 Oracle 10g 提供程序中，除非您知道您正在做其他可能会泄漏内存的事情。

Answer 3

不管怎样，我们已经在 .NET 4.0 中为 TraceSource 和 Switch 修复了这个问题。

我们仍然认为最好的做法是不要创建一堆不同的 TraceSource 实例（而是为每个源创建一个静态实例并跨线程共享它们），但在某些情况下，如果您使用的是第三方库，则这是不可能的你无法修复。

Answer 4

您使用 ODP.Net 吗？
请记住，ODP.Net 不是完全托管的，并且也有一个本机组件。
您是否使用任何其他本机资源，例如 ActiveDirectory 等。请记住，即使您有 .Net 程序集，对于 AD 等内容来说，它也是 COM 上的一个薄层。 我在我使用的 AD 代码中发现了大量内存泄漏。 不过，我的 ODP.Net 没有出现内存问题，而且我公司的企业服务是使用 ODP.Net 运行的。

Answer 5

private void TidyWeakReferences(System.Diagnostics.TraceSource source) {

        try {
            // Clear down the Switch's WeakReferences
            TidyList(source, typeof(System.Diagnostics.Switch).GetFields(BindingFlags.NonPublic | BindingFlags.Static));
            // Clear down the Source's WeakReferences
            TidyList(source, typeof(System.Diagnostics.TraceSource).GetFields(BindingFlags.NonPublic | BindingFlags.Static));
        }
        catch { /* Nothing we can do here */ }
    }

private void TidyList(System.Diagnostics.TraceSource source, FieldInfo[] info) {

        List<WeakReference> list = null;

        foreach (FieldInfo fi in info) {

            if (fi.Name == "switches" | fi.Name == "tracesources") {

                list = (List<WeakReference>)fi.GetValue(null);
                lock (list) {
                    for (int i = list.Count - 1; i >= 0; i--) {
                        // Check to see if the GC has already collected these objects
                        if (!list[i].IsAlive) {
                            // It's dead, so remove it from the List (as .NET Framework 4.0 SHOULD fix.)
                            list.RemoveAt(i);
                        }
                    }
                }
            }
        }

Answer 6

这个调试经验的链接应该添加到这个讨论中。 它补充了@thehowler 发布的解决方法。

基本上，TraceSource 的每个新分配都会添加到不被垃圾收集的 WeakReference 列表中。