C# 垃圾收集器行为

Question

我们有一个用 C# 编写的应用程序，它控制我们的一个设备并对这个设备给我们的信号使用react。

基本上，应用程序创建线程、处理操作(访问数据库等)并与此设备通信。

在应用程序的生命周期中，它会创建对象并释放它们，到目前为止，我们让垃圾收集器处理我们的内存。我读到过强烈建议让 GC 在不干扰的情况下完成它的工作。

现在我们面临的问题是我们的应用程序的进程不断增长，一步一步地增长。示例:

当应用程序增长时，它似乎有“波浪”，突然间，应用程序释放了一些内存，但同时似乎留下了内存泄漏。

我们正在尝试使用一些内存分析器来调查应用程序，但我们想深入了解垃圾收集器的工作原理。

• 我在这里找到了一篇很棒的文章:The Danger of Large Objects
• 我还在此处找到了官方文档:MSDN

你们知道另一个非常非常深入的 GC 文档吗？

编辑:

这是一个说明应用程序行为的屏幕截图:

您可以清楚地看到我们在非常规则的图案上产生的“波浪”效果。

附属问题:

我发现我的 GC Collection 2 堆非常大，并且遵循与我的应用程序使用的总字节数相同的模式。我想这是完全正常的，因为我们的大多数对象至少会在 2 次垃圾回收中存活下来(例如单例类等)...您怎么看？

Answer 1

您描述的行为是在大型对象堆 (LOH) 上创建的对象的典型问题。但是，您的内存消耗似乎稍后会恢复到某个较低的值，因此请再次检查它是否真的是 LOH 问题。

您显然已经意识到这一点，但不太明显的是 LOH 上的对象大小存在异常。

如文档中所述，大小超过 85000 字节的对象最终会出现在 LOH 上。但是，出于某种原因(可能是“优化”)，长度超过 1000 个元素的 double 组也最终出现在此处:

double[999] smallArray = ...; // ends up in 'normal', Gen-0 heap
double[1001] bigArray = ...; // ends up in LOH

这些数组会导致碎片化的 LOH，这需要更多内存，直到出现内存不足异常。

我被这个困扰了，因为我们有一个应用程序接收一些传感器读数作为 double 组，这导致 LOH 碎片整理，因为每个数组的长度略有不同(这些是不同频率的实时数据读数，由非实时采样过程)。我们通过实现自己的缓冲池解决了这个问题。