.NET陷阱之五:奇怪的OutOfMemoryException——大对象堆引起的问题与对策
2013-04-16 20:42
465 查看
我们在开发过程中曾经遇到过一个奇怪的问题:当软件加载了很多比较大规模的数据后,会偶尔出现OutOfMemoryException异常,但通过内存检查工具却发现还有很多可用内存。于是我们怀疑是可用内存总量充足,但却没有足够的连续内存了——也就是说存在很多未分配的内存空隙。但不是说.NET运行时的垃圾收集器会压缩使用中的内存,从而使已经释放的内存空隙连成一片吗?于是我深入研究了一下垃圾回收相关的内容,最终明确的了问题所在——大对象堆(LOH)的使用。如果你也遇到过类似的问题或者对相关的细节有兴趣的话,就继续读读吧。
如果没有特殊说明,后面的叙述都是针对32位系统。
首先我们来探讨另外一个问题:不考虑非托管内存的使用,在最坏情况下,当系统出现OutOfMemoryException异常时,有效的内存(程序中有GC Root的对象所占用的内存)使用量会是多大呢?2G? 1G? 500M? 50M?或者更小(是不是以为我在开玩笑)?来看下面这段代码(参考 https://www.simple-talk.com/dotnet/.net-framework/the-dangers-of-the-large-object-heap/)。
这段代码不断的交替分配一个较小的数组和一个较大的数组,其中较小数组的大小为90, 000字节,而较大数组的大小从16M字节开始,每次增加一个字节。如代码第15行所示,在每一次循环中bigBlock都会引用新分配的大数组,从而使之前的大数组变成可以被垃圾回收的对象。在发生OutOfMemoryException时,实际上代码会有count个小数组和一个大小为 16M + count 的大数组处于有效状态。最后代码输出了异常发生时小数组所占用的内存总量。
下面是在我的机器上的运行结果——和你的预测有多大差别?提醒一下,如果你要亲自测试这段代码,而你的机器是64位的话,一定要把生成目标改为x86。
考虑到32位程序有2G的可用内存,这里实现的使用率只有1%!
下面即介绍个中原因。需要说明的是,我只是想以最简单的方式阐明问题,所以有些语言可能并不精确,可以参考http://msdn.microsoft.com/en-us/magazine/cc534993.aspx以获得更详细的说明。
.NET的垃圾回收机制基于“Generation”的概念,并且一共有G0, G1, G2三个Generation。一般情况下,每个新创建的对象都属于于G0,对象每经历一次垃圾回收过程而未被回收时,就会进入下一个Generation(G0 -> G1 -> G2),但如果对象已经处于G2,则它仍然会处于G2中。
软件开始运行时,运行时会为每一个Generation预留一块连续的内存(这样说并不严格,但不影响此问题的描述),同时会保持一个指向此内存区域中尚未使用部分的指针P,当需要为对象分配空间时,直接返回P所在的地址,并将P做相应的调整即可,如下图所示。【顺便说一句,也正是因为这一技术,在.NET中创建一个对象要比在C或C++的堆中创建对象要快很多——当然,是在后者不使用额外的内存管理模块的情况下。】
![](https://oscdn.geek-share.com/Uploads/Images/Content/202005/09/58f5327ebf6e13a6cb8c1fc3e2328a91.jpg)
在对某个Generation进行垃圾回收时,运行时会先标记所有可以从有效引用到达的对象,然后压缩内存空间,将有效对象集中到一起,而合并已回收的对象占用的空间,如下图所示。
![](https://oscdn.geek-share.com/Uploads/Images/Content/202005/09/3a6446b5eecb8cb6be25cfbee9aa8028.jpg)
但是,问题就出在上面特别标出的“一般情况”之外。.NET会将对象分成两种情况区别对象,一种是大小小于85, 000字节的对象,称之为小对象,它就对应于前面描述的一般情况;另外一种是大小在85, 000之上的对象,称之为大对象,就是它造成了前面示例代码中内存使用率的问题。在.NET中,所有大对象都是分配在另外一个特别的连续内存(LOH, Large Object Heap)中的,而且,每个大对象在创建时即属于G2,也就是说只有在进行Generation 2的垃圾回收时,才会处理LOH。而且在对LOH进行垃圾回收时不会压缩内存!更进一步,LOH上空间的使用方式也很特殊——当分配一个大对象时,运行时会优先尝试在LOH的尾部进行分配,如果尾部空间不足,就会尝试向操作系统请求更多的内存空间,只有在这一步也失败时,才会重新搜索之前无效对象留下的内存空隙。如下图所示:
![](https://oscdn.geek-share.com/Uploads/Images/Content/202005/09/6c96137c807c8d5ed610b931c6fe3031.gif)
从上到下看
LOH中已经存在一个大小为85K的对象和一个大小为16M对象,当需要分配另外一个大小为85K的对象时,会在尾部分配空间;
此时发生了一次垃圾回收,大小为16M的对象被回收,其占用的空间为未使用状态,但运行时并没有对LOH进行压缩;
此时再分配一个大小为16.1M的对象时,分尝试在LOH尾部分配,但尾部空间不足。所以,
运行时向操作系统请求额外的内存,并将对象分配在尾部;
此时如果再需要分配一个大小为85K的对象,则优先使用尾部的空间。
所以前面的示例代码会造成LOH变成下面这个样子,当最后要分配16M + N的内存时,因为前面已经没有任何一块连续区域满足要求时,所以就会引发OutOfMemoryExceptiojn异常。
![](https://oscdn.geek-share.com/Uploads/Images/Content/202005/09/91b8d10f484150feaef746432556ca05.jpg)
要解决这一问题其实并不容易,但可以考虑下面的策略。
将比较大的对象分割成较小的对象,使每个小对象大小小于85, 000字节,从而不再分配在LOH上;
尽量“重用”少量的大对象,而不是分配很多大对象;
每隔一段时间就重启一下程序。
最终我们发现,我们的软件中使用数组(List<float>)保存了一些曲线数据,而这些曲线的大小很可能会超过了85, 000字节,同时曲线对象的个数也非常多,从而对LOH造成了很大的压力,甚至出现了文章开头所描述的情况。针对这一情况,我们采用了策略1的方法,定义了一个类似C++中deque的数据结构,它以分块内存的方式存储数据,而且保证每一块的大小都小于85, 000,从而解决了这一问题。
此外要说的是,不要以为64位环境中可以忽略这一问题。虽然64位环境下有更大的内存空间,但对于操作系统来说,.NET中的LOH会提交很大范围的内存区域,所以当存在大量的内存空隙时,即使不会出现OutOfMemoryException异常,也会使得内页页面交换的频率不断上升,从而使软件运行的越来越慢。
最后分享我们定义的分块列表,它对IList<T>接口的实现行为与List<T>相同,代码中只给出了比较重要的几个方法。
如果没有特殊说明,后面的叙述都是针对32位系统。
首先我们来探讨另外一个问题:不考虑非托管内存的使用,在最坏情况下,当系统出现OutOfMemoryException异常时,有效的内存(程序中有GC Root的对象所占用的内存)使用量会是多大呢?2G? 1G? 500M? 50M?或者更小(是不是以为我在开玩笑)?来看下面这段代码(参考 https://www.simple-talk.com/dotnet/.net-framework/the-dangers-of-the-large-object-heap/)。
public class Program { static void Main(string[] args) { var smallBlockSize = 90000; var largeBlockSize = 1 << 24; var count = 0; var bigBlock = new byte[0]; try { var smallBlocks = new List<byte[]>(); while (true) { GC.Collect(); bigBlock = new byte[largeBlockSize]; largeBlockSize++; smallBlocks.Add(new byte[smallBlockSize]); count++; } } catch (OutOfMemoryException) { bigBlock = null; GC.Collect(); Console.WriteLine("{0} Mb allocated", (count * smallBlockSize) / (1024 * 1024)); } Console.ReadLine(); } }
这段代码不断的交替分配一个较小的数组和一个较大的数组,其中较小数组的大小为90, 000字节,而较大数组的大小从16M字节开始,每次增加一个字节。如代码第15行所示,在每一次循环中bigBlock都会引用新分配的大数组,从而使之前的大数组变成可以被垃圾回收的对象。在发生OutOfMemoryException时,实际上代码会有count个小数组和一个大小为 16M + count 的大数组处于有效状态。最后代码输出了异常发生时小数组所占用的内存总量。
下面是在我的机器上的运行结果——和你的预测有多大差别?提醒一下,如果你要亲自测试这段代码,而你的机器是64位的话,一定要把生成目标改为x86。
23 Mb allocated
考虑到32位程序有2G的可用内存,这里实现的使用率只有1%!
下面即介绍个中原因。需要说明的是,我只是想以最简单的方式阐明问题,所以有些语言可能并不精确,可以参考http://msdn.microsoft.com/en-us/magazine/cc534993.aspx以获得更详细的说明。
.NET的垃圾回收机制基于“Generation”的概念,并且一共有G0, G1, G2三个Generation。一般情况下,每个新创建的对象都属于于G0,对象每经历一次垃圾回收过程而未被回收时,就会进入下一个Generation(G0 -> G1 -> G2),但如果对象已经处于G2,则它仍然会处于G2中。
软件开始运行时,运行时会为每一个Generation预留一块连续的内存(这样说并不严格,但不影响此问题的描述),同时会保持一个指向此内存区域中尚未使用部分的指针P,当需要为对象分配空间时,直接返回P所在的地址,并将P做相应的调整即可,如下图所示。【顺便说一句,也正是因为这一技术,在.NET中创建一个对象要比在C或C++的堆中创建对象要快很多——当然,是在后者不使用额外的内存管理模块的情况下。】
![](https://oscdn.geek-share.com/Uploads/Images/Content/202005/09/58f5327ebf6e13a6cb8c1fc3e2328a91.jpg)
在对某个Generation进行垃圾回收时,运行时会先标记所有可以从有效引用到达的对象,然后压缩内存空间,将有效对象集中到一起,而合并已回收的对象占用的空间,如下图所示。
![](https://oscdn.geek-share.com/Uploads/Images/Content/202005/09/3a6446b5eecb8cb6be25cfbee9aa8028.jpg)
但是,问题就出在上面特别标出的“一般情况”之外。.NET会将对象分成两种情况区别对象,一种是大小小于85, 000字节的对象,称之为小对象,它就对应于前面描述的一般情况;另外一种是大小在85, 000之上的对象,称之为大对象,就是它造成了前面示例代码中内存使用率的问题。在.NET中,所有大对象都是分配在另外一个特别的连续内存(LOH, Large Object Heap)中的,而且,每个大对象在创建时即属于G2,也就是说只有在进行Generation 2的垃圾回收时,才会处理LOH。而且在对LOH进行垃圾回收时不会压缩内存!更进一步,LOH上空间的使用方式也很特殊——当分配一个大对象时,运行时会优先尝试在LOH的尾部进行分配,如果尾部空间不足,就会尝试向操作系统请求更多的内存空间,只有在这一步也失败时,才会重新搜索之前无效对象留下的内存空隙。如下图所示:
![](https://oscdn.geek-share.com/Uploads/Images/Content/202005/09/6c96137c807c8d5ed610b931c6fe3031.gif)
从上到下看
LOH中已经存在一个大小为85K的对象和一个大小为16M对象,当需要分配另外一个大小为85K的对象时,会在尾部分配空间;
此时发生了一次垃圾回收,大小为16M的对象被回收,其占用的空间为未使用状态,但运行时并没有对LOH进行压缩;
此时再分配一个大小为16.1M的对象时,分尝试在LOH尾部分配,但尾部空间不足。所以,
运行时向操作系统请求额外的内存,并将对象分配在尾部;
此时如果再需要分配一个大小为85K的对象,则优先使用尾部的空间。
所以前面的示例代码会造成LOH变成下面这个样子,当最后要分配16M + N的内存时,因为前面已经没有任何一块连续区域满足要求时,所以就会引发OutOfMemoryExceptiojn异常。
![](https://oscdn.geek-share.com/Uploads/Images/Content/202005/09/91b8d10f484150feaef746432556ca05.jpg)
要解决这一问题其实并不容易,但可以考虑下面的策略。
将比较大的对象分割成较小的对象,使每个小对象大小小于85, 000字节,从而不再分配在LOH上;
尽量“重用”少量的大对象,而不是分配很多大对象;
每隔一段时间就重启一下程序。
最终我们发现,我们的软件中使用数组(List<float>)保存了一些曲线数据,而这些曲线的大小很可能会超过了85, 000字节,同时曲线对象的个数也非常多,从而对LOH造成了很大的压力,甚至出现了文章开头所描述的情况。针对这一情况,我们采用了策略1的方法,定义了一个类似C++中deque的数据结构,它以分块内存的方式存储数据,而且保证每一块的大小都小于85, 000,从而解决了这一问题。
此外要说的是,不要以为64位环境中可以忽略这一问题。虽然64位环境下有更大的内存空间,但对于操作系统来说,.NET中的LOH会提交很大范围的内存区域,所以当存在大量的内存空隙时,即使不会出现OutOfMemoryException异常,也会使得内页页面交换的频率不断上升,从而使软件运行的越来越慢。
最后分享我们定义的分块列表,它对IList<T>接口的实现行为与List<T>相同,代码中只给出了比较重要的几个方法。
public class BlockList<T> : IList<T> { private static int maxAllocSize; private static int initAllocSize; private T[][] blocks; private int blockCount; private int[] blockSizes; private int version; private int countCache; private int countCacheVersion; static BlockList() { var type = typeof(T); var size = type.IsValueType ? Marshal.SizeOf(default(T)) : IntPtr.Size; maxAllocSize = 80000 / size; initAllocSize = 8; } public BlockList() { blocks = new T[8][]; blockSizes = new int[8]; blockCount = 0; } public void Add(T item) { int blockId = 0, blockSize = 0; if (blockCount == 0) { UseNewBlock(); } else { blockId = blockCount - 1; blockSize = blockSizes[blockId]; if (blockSize == blocks[blockId].Length) { if (!ExpandBlock(blockId)) { UseNewBlock(); ++blockId; blockSize = 0; } } } blocks[blockId][blockSize] = item; ++blockSizes[blockId]; ++version; } public void Insert(int index, T item) { if (index > Count) { throw new ArgumentOutOfRangeException("index"); } if (blockCount == 0) { UseNewBlock(); blocks[0][0] = item; blockSizes[0] = 1; ++version; return; } for (int i = 0; i < blockCount; ++i) { if (index >= blockSizes[i]) { index -= blockSizes[i]; continue; } if (blockSizes[i] < blocks[i].Length || ExpandBlock(i)) { for (var j = blockSizes[i]; j > index; --j) { blocks[i][j] = blocks[i][j - 1]; } blocks[i][index] = item; ++blockSizes[i]; break; } if (i == blockCount - 1) { UseNewBlock(); } if (blockSizes[i + 1] == blocks[i + 1].Length && !ExpandBlock(i + 1)) { UseNewBlock(); var newBlock = blocks[blockCount - 1]; for (int j = blockCount - 1; j > i + 1; --j) { blocks[j] = blocks[j - 1]; blockSizes[j] = blockSizes[j - 1]; } blocks[i + 1] = newBlock; blockSizes[i + 1] = 0; } var nextBlock = blocks[i + 1]; var nextBlockSize = blockSizes[i + 1]; for (var j = nextBlockSize; j > 0; --j) { nextBlock[j] = nextBlock[j - 1]; } nextBlock[0] = blocks[i][blockSizes[i] - 1]; ++blockSizes[i + 1]; for (var j = blockSizes[i] - 1; j > index; --j) { blocks[i][j] = blocks[i][j - 1]; } blocks[i][index] = item; break; } ++version; } public void RemoveAt(int index) { if (index < 0 || index >= Count) { throw new ArgumentOutOfRangeException("index"); } for (int i = 0; i < blockCount; ++i) { if (index >= blockSizes[i]) { index -= blockSizes[i]; continue; } if (blockSizes[i] == 1) { for (int j = i + 1; j < blockCount; ++j) { blocks[j - 1] = blocks[j]; blockSizes[j - 1] = blockSizes[j]; } blocks[blockCount - 1] = null; blockSizes[blockCount - 1] = 0; --blockCount; } else { for (int j = index + 1; j < blockSizes[i]; ++j) { blocks[i][j - 1] = blocks[i][j]; } blocks[i][blockSizes[i] - 1] = default(T); --blockSizes[i]; } break; } ++version; } private bool ExpandBlock(int blockId) { var length = blocks[blockId].Length; if (length == maxAllocSize) { return false; } length = Math.Min(length * 2, maxAllocSize); Array.Resize(ref blocks[blockId], length); return true; } private void UseNewBlock() { if (blockCount == blocks.Length) { Array.Resize(ref blocks, blockCount * 2); Array.Resize(ref blockSizes, blockCount * 2); } blocks[blockCount] = new T[initAllocSize]; blockSizes[blockCount] = 0; ++blockCount; } }
相关文章推荐
- .NET陷阱之五:奇怪的OutOfMemoryException——大对象堆引起的问题与对策
- .NET陷阱之五:奇怪的OutOfMemoryException——大对象堆引起的问题与对策
- .NET陷阱之五:奇怪的OutOfMemoryException——大对象堆引起的问题与对策
- .NET陷阱之奇怪的OutOfMemoryException
- ASP.NET 中关于 System.OutOfMemoryException 的问题与解决方法
- .NET陷阱之奇怪的OutOfMemoryException
- 警惕麦咖啡的"缓冲区溢出保护"引起的ASP.NET 中 System.OutOfMemoryException 的错误
- ASP.NET 中关于 System.OutOfMemoryException 的问题与解决方法
- 解决 ASP.NET 中 System.OutOfMemoryException 的问题
- Tomcat溢出问题Exception in thread "http-apr-8080-exec-8" java.lang.OutOfMemoryError: PermGen space
- .NET Out Of Memory Exception - Used 1.3GB but have 16GB installed
- 解决Android加载大图片内存溢出的问题(OutofMemoryException)
- .Net System.OutOfMemoryException
- Android out of memory 彻底解决Android因加载多个大图引起的OutOfMemoryError,内存溢出的问题
- Net 内存溢出(System.OutOfMemoryException)的常见情况和处理方式总结
- ASP.NET中的OutOfMemoryException
- Android out of memory 彻底解决Android因加载多个大图引起的OutOfMemoryError,内存溢出的问题 .
- 解決 ASP.NET 中 System.OutOfMemoryException 的問題
- 彻底解决Android因加载多个大图引起的OutOfMemoryError,内存溢出的问题
- 解決 ASP.NET 中 System.OutOfMemoryException 的問題