.net - 生成报告时诊断 .NET OutOfMemoryException

Question

我的任务是改进一段生成大量报告的代码，以我认为合适的任何方式。

生成了大约 10 个相同的报告(针对数据库的每个“部分”)，它们的代码类似于:

GeneratePurchaseReport(Country.France, ProductType.Chair);
GC.Collect();
GeneratePurchaseReport(Country.France, ProductType.Table);
GC.Collect();
GeneratePurchaseReport(Country.Italy, ProductType.Chair);
GC.Collect();
GeneratePurchaseReport(Country.Italy, ProductType.Table);
GC.Collect();

如果我删除那些 GC.Collect()调用时，报告服务崩溃并显示 OutOfMemoryException .

大部分内存保存在一个巨大的 List<T> 中。里面是GeneratePurchaseReport并且一旦退出就不再使用 - 这就是完整的 GC 收集将回收内存的原因。

我的问题有两个:

1. 为什么 GC 不自己执行此操作？一旦它在第二个 GeneratePurchaseReport 上耗尽内存它应该在崩溃和燃烧之前进行完整的收集，不是吗？
2. 是否有我可以通过某种方式提高的内存限制？如果将数据交换到磁盘，我一点也不介意，但 .net 进程使用的内存甚至比可用的 2.5GB RAM 还要少!我希望它只有在地址空间用完时才会崩溃，但在 64 位机器上我怀疑这种情况会这么快发生。

Answer 1

阅读大对象堆。

我认为正在发生的事情是随着时间的推移构建并附加各个报告的最终文档，这样在每次附加操作时都会创建一个新文档并丢弃旧文档(这可能在幕后发生)。该文档(最终)大于大型对象堆上存储的 85,000 字节阈值。

在这种情况下，您实际上并没有使用那么多物理内存——它仍然可用于其他进程。您正在使用的是您的程序可用的地址空间。 Windows 中的每个进程都有自己的(通常)2GB 可用地址空间。随着时间的推移，当您分配不断增长的报告文档的新副本时，在收集之前的副本时，您会在 LOH 中留下许多漏洞。先前对象释放的内存实际上不再使用，可供其他进程使用，但地址空间仍然丢失；它是零散的，需要压缩。最终这个地址空间被填满，你会得到一个 OutOfMemory 异常。

有证据表明调用 GC.Collect() 允许对 LOH 进行一些压缩，但这并不是一个完美的解决方案。几乎我在该主题上阅读的所有其他内容都表明 GC.Collect() 根本不应该压缩 LOH，但我已经看到了一些轶事报告(一些在 Stack Overflow 上)，其中调用 GC.Collect()实际上能够避免 LOH 碎片造成的 OutOfMemory 异常。

一个“更好”的解决方案(确保您永远不会耗尽内存——使用 GC.Collect() 压缩 LOH 是不可靠的)是将您的报告拆分为小于85000 字节，并在最后将它们全部写入单个缓冲区，或者使用在增长时不会丢弃您之前工作的数据结构。不幸的是，这可能是更多的代码。

这里一个相对简单的选择是为比您的最大报表更大的 MemoryStream 对象分配一个缓冲区，然后在您构建报表时写入 MemoryStream。这样你就永远不会留下碎片。如果这只是写入磁盘，您甚至可以直接使用 FileStream(可能通过 TextWriter，以便以后更改)。如果此选项解决了您的问题，我想在对此答案的评论中听到它。