9.6. OOM案例汇总
OOM产生的原因多种多样，例如，有些程序未必产生OOM，但是会不断FGC，或是CPU飙高但内存回收特别少。出现OOM的场景进行记录，如下所示：
【案例1】硬件升级系统反而卡顿的问题，如调优实战小节中的调优实战1。
【案例2】线程池不当运用产生OOM问题，如调优实战小节中的调优实战2。
【案例3】jira问题，详细信息见附件。该问题导致的现象是系统出现FGC很频繁，实际系统不断重启。解决方案是更换垃圾回收器G1，换用更大的内存。
【案例4】tomcat中的http问题，详细信息见附件。该问题出现的原因是网管将http-header-size参数设置的过大，导致在连接http时，http对象头就会占用大量的空间，导致空间不足。
【案例5】 lambda表达式导致方法区溢出问题。
【案例6】直接内存溢出问题，该问题很少见，例如《深入理解Java虚拟机》P59，使用Unsafe分配直接内存，或者使用NIO的问题。
【案例7】栈溢出问题，-Xss设定太小。
【案例8】比较一下这两段程序的异同，分析哪一个是更优的写法：
Object o = null;
for(int i=0; i<100; i++) {
o = new Object();
//业务处理
}
for(int i=0; i<100; i++) {
Object o = new Object();
}
【案例9】重写finalize引发频繁GC。该问题出现的现象是小米云的HBase同步系统，系统通过nginx访问超时报警。解决方案：C++程序员重写finalize引发频繁GC问题，为什么C++程序员会重写finalize？（new delete） finalize耗时比较长（200ms）
【案例10】如果有一个系统，内存一直消耗不超过10%，但是观察GC日志，发现FGC总是频繁产生。造成的原因：程序里面不断执行指令System.gc()
【案例11】Distuptor有个可以设置链的长度，如果过大，然后对象大，消费完不主动释放，会溢出 (来自 死物风情)
【案例12】用jvm都会溢出，mycat用崩过，1.6.5某个临时版本解析sql子查询算法有问题，9个exists的联合sql就导致生成几百万的对象（来自 死物风情）
【案例13】new 大量线程，会产生 native thread OOM。解决方案：减少堆空间，预留更多内存产生native thread JVM内存占物理内存比例 50% - 80%，而且应该使用线程池创建线程。