第九章 JVM调优推荐

说明：本文主要参考自《分布式Java应用：基础与实践》

1、JVM的调优主要是内存的调优，主要调两个方面：

各个代的大小

垃圾收集器选择

2、各个代的大小

常用的调节参数

-Xmx

-Xms

-Xmn

-XX:SurvivorRatio

-XX:MaxTenuringThreshold

-XX:PermSize

-XX:MaxPermSize

原则

-Xmx==-Xms：防止堆内存频繁进行调整，调整的时机见《第一章 JVM内存结构》

-Xmn：通常设为-Xmx/4（这是我在企业中实习时的设置方式，系统运行正常、平稳、速度也快），林昊推荐的是-Xmx/3，所以-Xmn==-Xmx/4~-Xmx/3

调节时机：minor GC太频繁

-Xmn过小：minor GC太频繁；小对象可能也会直接进入年老代，提前导致Full GC

-Xmn过大：年轻代大了，minor GC的时间变长了；年老代变小了，Full GC会频繁

调节策略：若-Xmx可调大，则调大，且保持-Xmn==-Xmx/4~-Xmx/3；若-Xmx不可调大，在保持-Xmn==-Xmx/4~-Xmx/3的范围内增大-Xmn，若-Xmn也不可调了，则试着调大-XX:SurvivorRatio来看看情况

-XX:SurvivorRatio：默认8

-XX:SurvivorRatio过大：Eden变大，Survivor变小，minor GC可能减少，但是由于suvivor减小了，所以如果minor GC存活下来的对象大于suvivor，则会直接进入年老代

-XX:SurvivorRatio过小：Eden变小，Survivor变大，minor GC可能增多，但是由于suvivor变大了，能够存储更多存活下来的对象，进入年老代的对象可能会减少

-XX:MaxTenuringThreshold：默认为15

-XX:SurvivorRatio过大：对象在年轻代的存活时间变长，可能在年轻代就被回收掉而不必进入年老代，但是相应的复制的时候survivor区就会被占用更多的空间。

-XX:SurvivorRatio过大：对象在年轻代的存活时间变短，可能会早早进入年老代而失去在年轻代被回收的机会，但是相应的复制的时候survivor区也就有更多内存了，这样可能会避免部分大对象直接进入年老代

-XX:MaxPermSize==-XX:PermSize

在实际开发中，前台不要使用jsp，使用velocity等模板引擎技术

不要引入无关的jar

3、垃圾收集器选择

企业中最常用的两个组合：（这里由于大部分大型企业用的还是JDK1.6，所以G1不说）

关于下边两组垃圾收集器的详细原理见：第五章 JVM垃圾收集器（1）

Parallel Scavenge/Parallel Old

注重吞吐量（吞吐量越大，说明CPU利用率越高）

主要用于处理很多的CPU计算任务而用户交互任务较少的情况

也用于让JVM自动调优而我们袖手旁观的情况（-XX:+UseParallelOldGC，-XX:GCTimeRatio，-Xmx，-XX:+UseAdaptiveSizePolicy）

-XX:+UseParallelOldGC：指定使用该组合

ParNew/CMS

注重STW的缩短（该时间越短，用户体验越好，而且会减少部分请求的请求超时问题）

-XX:+UseConcMarkSweepGC：指定使用该组合

-XX:CMSInitiatingOccupancyFraction：来指定当年老代空间满了多少后（百分比）进行垃圾回收

关于上边两种组合的说明

一般而言，在企业中，机器的CPU数量都比较多，且CPU的计算能力也不会成为瓶颈，所以对于CMS的并发标记与并发清除阶段，会占用CPU资源的问题，其实不是大事儿；而对于Parallel的注重吞吐量的问题也就不是什么大事儿了，毕竟CPU是强大的

所以，ParNew/CMS是首选（在G1不能用的情况下），Parallel Scavenge/Parallel Old只在想让JVM自动管理内存的情况下使用

注意：在实际调优过程中，可以使用jstat、jconsole、visualVM或GC日志的检测数据来调，具体的示例见《深入理解java虚拟机（第二版）》p142对eclipse运行速度的调优。

关于GC日志的参数含义与每一种垃圾收集器的GC日志的格式，查看《深入理解Java虚拟机（第二版）》的P89和《深入分析java web技术内幕（修订版）》的P224