有效预防.NET应用程序OOM的经验备忘

根据个人的开发和系统调优经验，大部分的内存溢出(及内存泄漏)都和不好的开发习惯有直接关系，有几个开发经验可以有效预防OOM，总结下贴出来和大家分享。

 

一、批量和分页

老生常谈的话题，简单，但是非常实用。

每个合格的coder对数据的处理，必须要有分页或批量多次的意识。大数据量的读取或查询结果集是内存占用大户，是系统性能下降的直接原因之一。

在典型的互联网web应用中，数据量较大且高并发的情况下，不分页，或者不进行批量处理，每次总是取出很多用户数据，很容易造成内存开销过大，系统内存吃紧。再比如我们有时候进行文件操作，读取文件内容的时候就要斟酌考虑文件有多大。

如果你的项目中还在出现不分青红皂白一次查询返回N（N有多大？）条记录的DataSet、DataTable或者列表记录等等情况，或者查询大量数据写入临时表，或者一次读取很大文件内容......呵呵。

 

二、慎用静态

这个也是常见但是比较隐式的引起内存泄露的元凶之一。

静态类、静态字段、静态属性，静态委托，静态方法…静态的好处当然显而易见，比如调用方便，常驻内存提高性能等等，所以，有些代码索性静态到底，除了实体层，在表现层（说起来非常可怕，我曾经在web应用程序中看到竟然有人名目张胆地大肆使用静态字段），数据访问层、业务逻辑层、公共组件、配置管理等等等等，能静态的全给它用上静态。

比起大数据查询造成的常发性的内存不足，使用静态太多的应用程序一时半会也不会内存泄露。可随着系统的运行，静态的东西越来越多，内存开销也就越大，由于GC的回收策略，无效的静态所占内存又不容易及时释放，久而久之就造成了内存不足。

使用静态的情况在分层应用程序中非常常见，而且由于它的好处容易得到体现而隐藏的风险不容易暴露出来，所以很多程序员还是非常执着地使用静态。

 

三、二方库、三方库，非托管资源，优先使用Dispose模式

有些应用程序需要借助包装的二方库或者三方库，或者使用了非托管资源，如com组件等等，由于.NET自动内存管理和回收，很多人觉得我用一下完成功能就Over了。

实际情况是你调用了别人的库，别人的库也很可能当仁不让地占用了你的内存而你还不自知。

每次调用别人的资源都应该有个警觉性：用你的类库可以，占用我的（内存）不行。

如果你熟悉自动内存管理，熟悉GC，理解Dispose模式，那么一定会在调用别人的资源的时候想着还是using一下为妙，或者，强制赋个null也是举手之劳，要相信某些良好的编程习惯可以让自动内存管理更有效。怕的就是很多人拿来主义，测试不充分，自己调用成功功能完成开发就OK了，交接给别人自己走人。

 

四、减少字符串临时对象

这个实在是太熟悉不过了，不论是什么形式的应用程序，哪里能少得了字符串的身影？

看到它们有人条件反射似地想到拼接字符串，想到驻留池等等等等。

没错，不合理地使用String进行操作也会造成内存不足异常，而且这绝不是耸人听闻。

举例来说，对于String的+=，很多应用程序中这个操作层出不穷。我们都知道+=操作会造成很多临时字符串对象，这些对象由于CLR对字符串的驻留处理，容易占用内存空间。如果是高并发的web应用程序，而字符串操作随处可见，且字符串的长度又不确定地长，前端页面各种各样的拼接，久而久之，内存占用就会是一个重大问题。CLR对字符串的优化处理使得字符串不被优先回收，如果字符串操作频繁，临时字符串较长（比如大于等于85000字节）而出现大对象堆的分配，那么更容易出现内存泄露。

很多人可能都会想到如何优化程序去降低string的临时对象的生成概率。对的，StringBuilder的出现就顺理成章了。

 

五、其他经验

1、Session的不当使用，尤其是使用InProc模式的会话，为了保持状态而选择使用Session，如用户访问量较大将极大消耗服务器资源，而且会出现Session丢失的不稳定现象，所以一般的站点都选择restful的无状态服务；

2、使用较为复杂的数据结构，比如字典里面嵌套字典，字典的键和值也使用字典，曾经碰到过一个非常奇葩的项目，至少5层字典嵌套…有人会反驳说字典是引用类型，而且自动垃圾回收等等等等等等，在OOM面前一切雄辩都苍白无力；

3、过深的继承链，这里尤其要说的是类继承，熟悉垃圾回收的应该都清楚GC回收原理，继承的存在有可能延长类的生命周期而不利于及时回收，所以，如果实际项目中出现继承的深度超过两位数，那一定是抽象出现问题了，重构是必然选择；

4、一些多媒体处理程序的开发中内存泄露情况也非常常见，比如使用GDI+开发画图程序等等，内存消耗严重，这时候托管代码开启dispose模式无比重要；

5、在使用lucene.net的过程中发现有时候创建索引会出现OOM，数据量上去以后，内存不足几乎不可避免，这个时候就必须考虑重新调整架构拆分索引文件分布处理了；

6、有时候调用office组件进行一些报表处理，发现内存好像一下子少了好多？使用7z压缩组件，如果多线程调用，好像也有内存吃紧的现象？

7、调用第三方邮件组件处理邮件和附件，CPU和内存开销都很不能让人满意；

8、不断地注册事件(Event)  请参考Artech的这篇和这篇

……

更多其他容易导致OOM的开发经验等你来补充。

 

六、警惕大对象

本文前面分析的几种情况流于经验和表象，还有一种直达问题本质的内存泄露原因需要分析。

如果你深入理解了内存回收原理以及大对象和大对象堆（Large Object Heap,LOH），那么大对象导致的内存碎片化问题就很好理解了。

简单来说：

1、任何大于等于85000字节的对象都被自动视为大对象，大对象从特殊的大对象堆中分配。大对象堆和小对象堆一样进行终结和释放，但是GC回收算法从来不对大对象堆（Large Object Heap）进行内存压缩整理，因为在堆中下移85000字节或更大的内存块会浪费太多的CPU时间；

2、在.NET中，CLR采用基于代（generation）的垃圾回收，大对象总被认为是第2代（generation）的一部分，GC分析哪些对象不可达，优先分析第0代和第1代，第2代的对象通常被认为长时间存活。

正是由于1和2所述的两个原因（主要原因还是第1个），在垃圾回收过程中容易造成内存碎片。这里推荐一篇老外写的流传甚广的文章供参考：the dangers of the LOH

随着应用程序的运行，如果LOH导致的内存碎片越来越多，内存有效使用率下降会非常严重，比如我们在web应用程序中+=拼接字符串（见第4条的分析），如果大于等于85000字节的字符串临时对象很多，那么用户量一上去，随着系统的运行，GC回收压力越来越大OOM的风险会变得更高。

虽然内存碎片化导致的OOM看上去似乎无解，但是如果写程序的人仔细分析解决问题，想方设法主动降低创建大对象的频率，那么内存泄露的可能就会降低，足够优秀健壮的程序不能彻底解决OOM，但是我们完全可以将风险发生的情况将至最低可能。

一个足够合格的coder肯定需要具备充足的分析和解决OOM问题的准备和经验，有很多分析和检查OOM的工具如ANTS Memory Profiler，还可以通过调试利器如windbg对内存dump文件进行分析。用好这些工具，让OOM无所遁形也不失为解决之道。

最后，本文是今年春节前的最后一篇，提前祝大家节日快乐。文章写得太精彩了，完全可以用流水账来形容╮(╯_╰)╭，自我鼓励一下结束，哈哈。

 

参考：

<<CLR via C#>>

the dangers of the LOH

<<深入理解Java虚拟机>>