.NET陷阱之奇怪的OutOfMemoryException.pdf

.NET 陷阱之奇怪的OutOfMemoryException 我们在开发过程中曾经遇到过一个奇怪的问题：当软件加载了很多比较大规模的数据后，会偶尔出现OutOfMemoryException 异常，但通 过内存检查工具却发现还有很多可用内存。于是我们怀疑是可用内存总量充足，但却没有足够的连续内存了——也就是说存在很多未分配 的内存空隙。但不是说.NET 运行时的垃圾收集器会压缩使用中的内存，从而使已经释放的内存空隙连成一片吗？于是我深入研究了一下垃 圾回收相关的内容，最终明确的了问题所在——大对象堆（LOH）的使用。如果你也遇到过类似的问题或者对相关的细节有兴趣的话，就 继续读读吧。 如果没有特殊说明，后面的叙述都是针对32 位系统。 首先我们来探讨另外一个问题：不考虑非托管内存的使用，在最坏情况下，当系统出现OutOfMemoryException 异常时，有效的内存（程 序中有GC Root 的对象所占用的内存）使用量会是多大呢？2G？ 1G？ 500M？ 50M？或者更小（是不是以为我在开玩笑）？来看下面这段 代码（参考 /dotnet/.net-framework/the-dangers-of-the-large-object-heap/）。 1. public class Program 2. { 3. static void Main(string [] args) 4. { 5. var smallBlockSize = 90000; 6. var largeBlockSize = 1 24; 7. var count = 0; 8. var bigBlock = new byte [0]; 9. try 10. { 11. var smallBlocks = new Listbyte [](); 12. while (true) 13. { 14. GC.Collect(); 15. bigBlock = new byte [largeBlockSize]; 16. largeBlockSize++; 17. smallBlocks.Add(new byte [smallBlockSize]); 18. count++; 19. } 20. } 21. catch (OutOfMemoryException) 22. { 23. bigBlock = null; 24. GC.Collect(); 25. Console.WriteLine({0} Mb allocated, 26. (count * smallBlockSize) / (1024 * 1024)); 27. } 28. 29. Console.ReadLine(); 30. } 31. } 这段代码不断的交替分配一个较小的数组和一个较大的数组，其中较小数组的大小为90, 000 字节，而较大数组的大小从 16M 字节开始， 每次增加一个字节。如代码第15 行所示，在每一次循环中bigBlock 都会引用新分配的大数组，从而使之前的大数组变成可以被垃圾回收 的对象。在发生OutOfMemoryException 时，实际上代码会有count 个小数组和一个大小为 16M + count 的大数组处于有效状态。最后代 码输出了异常发生时小数组所占用的内存总量。 下面是在我的机器上的运行结果——和你的预测有多大差别？提醒一下，如果你要亲自测试这段代码，而你的机器是64 位的话，一定要 把生成目标改为x86。 1. 23 Mb allocated 考虑到32 位程序有2G 的可用内存，这里实现的使用率只