说明：本文主要参考自《分布式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