不需要的垃圾收集

Question

在 Andrew Troelsen 所著的《C# 2010 和 .NET 4 平台》一书中的标题“强制垃圾收集”中写道：

“再次强调，.NET 的全部目的垃圾收集器代表我们管理内存。但是，在一些非常罕见的情况下，使用 GC.Collect() 以编程方式强制进行垃圾收集可能会有所帮助，具体来说：

• 您的应用程序即将进入一个块。您不希望被可能的垃圾收集中断的代码。 ... “

但是停下来！是否存在不需要垃圾收集的情况？我从未见过/读过类似的东西（当然是因为我的开发经验很少）。如果在您的实践中您做过类似的事情，请分享。对我来说 的一点。

这是非常有趣

Answer 1

是的，绝对存在垃圾收集不受欢迎的情况：当用户等待某些事情发生时，他们必须等待更长时间，因为代码在垃圾收集完成之前无法继续。

这就是 Troelsen 的观点：如果您有一个特定的点，您知道 GC 不会有问题并且可能能够收集大量垃圾，那么它那么激发它可能是一个好主意，以避免它在不太合适的时刻触发。

Answer 2

我运营一个与食谱相关的网站，并在内存中存储大量食谱及其成分使用情况的图表。由于我采用这种信息快速访问的方式，因此在加载应用程序时，我必须将几千兆数据加载到内存中，然后才能将数据组织成非常优化的图表。我在堆上创建了大量的微小对象，一旦构建了图表，这些对象就变得无法访问。

这一切都是在 Web 应用程序加载时完成的，可能需要 4-5 秒的时间。执行此操作后，我会调用 GC.Collect(); 因为我宁愿现在重新声明所有内存，也不愿在垃圾收集器崩溃时在传入 HTTP 请求期间可能阻塞所有线程清理所有这些短命的物体。我还认为现在最好清理一下，因为此时堆的碎片可能较少，因为到目前为止我的应用程序还没有真正执行任何其他操作。延迟此操作可能会导致创建更多对象，并且当 GC 自动运行时需要更多地压缩堆。

除此之外，在我 12 年的 .NET 编程生涯中，我从未遇到过想要强制垃圾收集器运行的情况。

Answer 3

建议您不要在代码中显式调用 Collect。你能找到它有用的情况吗？

其他人已经详细说明了一些，毫无疑问还有更多。不过，首先要明白的是，不要这样做。这是最后的手段，研究其他选项，了解 GC 的工作原理，查看代码受到的影响，遵循设计的最佳实践。

在错误的位置调用Collect 会让你的性能变得更差。更糟糕的是，依赖它会让你的代码变得非常脆弱。调用 Collect 有益或最终无害所需的罕见条件可以通过对代码进行简单更改而完全消除，这将导致意外的 OOM、性能缓慢等。

Answer 4

我在性能测量之前调用它，这样 GC 就不会伪造结果。

另一种情况是内存泄漏的单元测试：

object doesItLeak = /*...*/; //The object you want to have tested
WeakReference reference = new WeakRefrence(doesItLeak); 
GC.Collect();
GC.WaitForPendingFinalizers();
GC.Collect();

Assert.That(!reference.IsAlive);

除此之外，我没有遇到过它实际上有帮助的情况。
特别是在生产代码中，恕我直言，永远不应该找到 GC.Collect 。

Answer 5

这种情况非常罕见，但 GC 可能是一个相当昂贵的过程，因此如果有一个特定的部分对时间敏感，您不希望该部分被 GC 中断。

Answer 6

您的应用程序即将输入您没有输入的代码块
希望被可能的垃圾收集中断。 ...

一个非常可疑的论点（尽管如此，它被大量使用）。

Windows 不是实时操作系统。您的代码（线程/进程）始终可以被操作系统调度程序抢占。您无法保证对 CPU 的访问。

所以归结为：GC 运行的时间与时隙（约 20 毫秒）相比如何？

关于这方面的硬数据很少，我搜索了几次。

根据我自己的观察（非常非正式），第 0 代集合是 << 40 毫秒，通常要短得多。完整的第 2 代可能会运行约 100 毫秒，甚至可能更多。

因此，被 GC 中断的“风险”与被换成另一个进程的风险是同一数量级的。而后者是你无法控制的。