我一直在尝试在此Web服务中诊断此30 MB内存泄漏。它使用标准存储过程从SQL获得一些批量获取。每个“批量”返回大约10,000-50,000行。 Web服务生成其报告并将其发送给调用者。
似乎每当您调用此报告时，30 MB内存被“吃掉”而未被释放。因此，如果您拨打相同的呼叫大约1,000次，则3 GB系统的内存不足。如果您回收应用程序池，则会释放内存。你可以坐在那里一天，不会释放内存。所以超时时间，网络服务器内存不足。
我浏览了代码，然后分析了它，并最终确定这些3“批量”获取得到了适量的数据。每个都取出10 MB，并且在完成后不会回复。存储的过程很好。关于调用的唯一奇怪的事情是它使用LINQ来调用存储的proc并使用XML映射文件将数据转换为Poco对象。
我尝试更改它，以便每次调用存储过程时都使用新的DataContext，然后将DataContext设置为null。我尝试将所有类型的对象设置为null，然后调用GC.Collect，并且在您回收应用程序池之前，mem仍然被吃掉并且不会被释放。
我很感激任何线索。我怀疑这与LINQ和大数据返回有关。
答案 0 :(得分：4)
这是垃圾收集的丑陋一面：开发人员倾向于认为他们不再需要担心释放内存。但这并不完全正确！
某些类实例必须是Disposed（因为它在.Net中调用）。实际上，实现IDisposable的每个对象都必须由开发人员处理其内存周期。
Streams就是一个很好的例子。流是一次性的，它们通常携带更大量的数据（大于简单的字符串）。想象一下，每5秒处理一个2KB流的服务。那不太对吗？比方说，它是一个小型XML。但是如果你不处理它会发生什么？好吧，你当然可以自己做数学，但我会给你结果：~33.7 MB未使用的垃圾。
底线：处理你的一次性用品。