是否可以使用反射修改 ReadOnlyCollection

Question

我正在处理一个 SDK，只要主连接对象在范围内，它就会保留对其创建的每个对象的引用。定期创建新的连接对象会导致其他资源问题，这不是一个选项。

为了完成我需要做的事情，我必须迭代数千个这样的对象（几乎 100,000 个），虽然我当然不会保留对这些对象的引用，但我正在使用的 SDK 中的对象模型会保留这些引用。这会消耗内存，并且非常接近导致 OutOfMemoryExceptions。

这些对象存储在嵌套的 ReadOnlyCollections 中，所以我现在尝试的是在使用完这些集合后使用反射将其中一些集合设置为 null，以便垃圾收集器可以收集已使用的内存。

foreach (Build build in builds)
{
        BinaryFileCollection numBinaries = build.GetBinaries();
        foreach (BinaryFile binary in numBinaries)
        {
            this.CoveredBlocks += binary.HitBlockCount;
            this.TotalBlocks += binary.BlockCount;
            this.CoveredArcs += binary.HitArcCount;
            this.TotalArcs += binary.ArcCount;

            if (binary.HitBlockCount > 0)
            {
                this.CoveredSourceFiles++;
            }

            this.TotalSourceFiles++;

            foreach (Class coverageClass in binary.GetClasses())
            {
                if (coverageClass.HitBlockCount > 0)
                {
                    this.CoveredClasses++;
                }

                this.TotalClasses++;

                foreach (Function function in coverageClass.GetFunctions())
                {
                    if (function.HitBlockCount > 0)
                    {
                        this.CoveredFunctions++;
                    }

                    this.TotalFunctions++;
                }
            }

            FieldInfo fi = typeof(BinaryFile).GetField("classes", BindingFlags.NonPublic | BindingFlags.Instance);
            fi.SetValue(binary, null);
    }

当我检查 numBinaries[0] 中类成员的值时，它返回 null，这似乎完成了任务，但是当我运行此代码时，内存消耗不断增加，就像我不运行时一样快完全将类设置为空。

我试图弄清楚这种方法是否存在本质上的缺陷，或者是否有另一个对象保留对我所缺少的类 ReadOnlyCollection 的引用。

Answer 1

我能想到几个替代方案...

1. 逻辑上把它分开。您提到它“在连接期间”保留所有引用。你能做 10%，关闭它，打开一个新的，跳过这 10%，再拿 10%（总共 20%），等等？
2. 我们在这里谈论的是多少内存，这个工具会是长寿的东西吗？那么如果它在几分钟内使用大量 RAM 该怎么办？你真的遇到 OOM 了吗？如果您的系统有那么多可用 RAM 供程序使用，为什么不使用它呢？您为 RAM 付费了。这让我想起 Raymond Chen 的一篇 博客文章 大约 100% CPU消耗。
3. 如果您确实想了解是什么阻止了某些东西被垃圾收集，那么启动 SOS 并使用 !gcroot 是一个起点。

但尽管如此，如果这确实是一个问题，我会花更多时间与第 3 方 API 提供商合作 - 在某些时候他们可能会发布您想要的更新来打破这个问题 - 然后您将回到第一个方向，或者更糟糕的是，您可能会在产品中引入细微的错误。