遇到OOM如何处理？

首先，要搞清OOM的分类：
OMM主要三类： permgen OOM , heap OOM, stack overflow 
permgen OOM : 这个主要是由于加载的类太多，或者反射的类太多， 还有 调用 String.intend（jdk7之前）也会造成这个问题。所以出现了这个问题，就检查这三个方面；
heap OOM ： 基本是按照 1楼的方式就可以解决了，主要是因为一些无用对象没有及时释放造成的，检查代码加上 heap dump 去分析吧
stack overflow ： 这个主要是由于调用层数，或者递归深度太大造成的，看异常信息，基本上就能定位得出来了

把内存大户找出来。
1. 可通过命令定期抓取heap dump 或者 启动参数OOM时 自动抓取heap dump
2. 通过对比多个heap dump，以及heap dump的内容，找出内存大户
3. 分析占用的内存对象，是否是因为错误导致的内存未及时释放，或者 数据过多导致的内存溢出
4. 根据原因，fix bug 或者 修改方案

堆/Heap 
JVM管理的内存叫堆；在32Bit操作系统上有4G的限制，一般来说Windows下为2G，而Linux 下为3G；64Bit的就没有这个限制。 
JVM初始分配的内存由-Xms指定，默认是物理内存的1/64但小于1G。 
JVM最大分配的内存由-Xmx指定，默认是物理内存的1/4但小于1G。 
默认空余堆内存小于40%时，JVM就会增大堆直到-Xmx的最大限制，可以由 -XX:MinHeapFreeRatio=指定。 
默认空余堆内存大于70%时，JVM会减少堆直到-Xms的最小限制，可以由 -XX:MaxHeapFreeRatio=指定。 
服务器一般设置-Xms、-Xmx相等以避免在每次GC后调整堆的大小，所以上面的两个参数没啥用。 

分代/堆模型 
分代是Java垃圾收集的一大亮点，根据对象的生命周期长短，把堆分为3个代：Young，Old和Permanent，根据不同代的特点采用不同的收集算法，可以扬长避短。可参考如下的模型图： 

GC的类型 
当每个代满了之后都会自动促发collection，各收集器触发的条件不一样，当然也可以通过一些参数进行强制设定。主要分为两种类型： 
Minor Collection：GC用较高的频率对young进行扫描和回收，采用复制算法。 
Major Collection：同时对Young和Old进行内存收集，也叫Full GC；因为成本关系对Old的检查回收频率要比Young低很多，采用标记清除/标记整理算法。可以通过调用代码System.gc()引发major collection，使用-XX:+DisableExplicitGC禁止它，或设为CMS并发 -XX:+ExplicitGCInvokesConcurrent。 

更为具体的阐述如下：

由于年轻代进进出出的人多而频繁，所以年轻代的GC也就频繁一点，但涉及范围也就年轻代这点弹丸之地内的对象，其特点就是少量，多次，但快速，称之为 Minor Collection。当年轻代的内存使用达到一定的阀值时，Minor Collection就被触发，Eden及某一Survior space（from space）之内存活的的对象被移到另一个空的Survior space（to space）中，然后from space和to space角色对调。当一个对象在两个survivor space之间移动过一定次数（达到预设的阀值）时，它就足够old了，够资格呆在年老代了。当然，如果survivor space比较小不足以容下所有live objects时，部分live objects也会直接晋升到年老代。

Survior spaces可以看作是Eden和年老代之间的缓冲，通过该缓冲可以检验一个对象生命周期是否足够的长，因为某些对象虽然逃过了一次Minor Collection，并不能说明其生命周期足够长，说不定在下一次Minor Collection之前就挂了。这样一定程度上确保了进入年老代的对象是货真价实的，减少了年老代空间使用的增长速度，也就降低年老代GC的频率。

当年老代或者永久代的内存使用达到一定阀值时，一次基于所有代的GC就触发了，其特定是涉及范围广（量大），耗费的时间相对较长（较慢），但是频率比较低（次数少），称之为Major Collection(Full Collection)。通常，首先使用针对年轻代的GC算法进行年轻代的GC，然后使用针对年老代的GC算法对年老代和永久代进行GC。 

调优总结

年轻代大小选择

响应时间优先的应用：尽可能设大，直到接近系统的最低响应时间限制（根据实际情况选择）。在此种情况下，年轻代收集发生的频率也是最小的。同时，减少到达年老代的对象。

吞吐量优先的应用：尽可能的设置大，可能到达Gbit的程度。因为对响应时间没有要求，垃圾收集可以并行进行，一般适合8CPU以上的应用。

年老代大小选择

响应时间优先的应用：年老代使用并发收集器，所以其大小需要小心设置，一般要考虑并发会话率和会话持续时间等一些参数。如果堆设置小了，可以会造成内存碎片、高回收频率以及应用暂停而使用传统的标记清除方式；如果堆大了，则需要较长的收集时间。最优化的方案，一般需要参考以下数据获得：

1. 并发垃圾收集信息  
2. 持久代并发收集次数  
3.  传统GC信息  
4.  花在年轻代和年老代回收上的时间比例