JVM调优过程
最优参数设置
禁止动态调整
将新生代和老年代的大小设置为固定，非动态调整的，包括：
- 堆的最大值和最小值相同：-Xms和-Xmx设置为相同的值；
- 新生代的最大值和最小值相同：-Xmn；
堆和新生代的大小固定后，老年代的大小也被固定。原因是：动态调整新生代和老年代都会触发FGC，降低吞吐量、增加延时。
禁止显式GC
参数设置：-XX:+DisableExplicitGC；
原因：
- 代码中显示调用System.gc()，只是建议JVM进行垃圾回收，但是到底会不会执行垃圾回收是不确定的，可能会进行垃圾回收，也可能不会。
- System.gc()会触发FGC，严重影响性能。
查看：https://stackoverflow.com/questions/2414105/why-is-it-bad-practice-to-call-system-gc
开启永久代垃圾回收调优
在CMS中，Hotspot VM默认不会对永久代进行垃圾回收。对于存在频繁类加载情况的应用可以开启并发回收永久代开关。
参数设置：-XX:+CMSClassUnloadingEnabled；
限定堆外内存上限
目的：防止堆外内存泄露触发OOM；
参数设置：-XX:MaxDirectMemorySize=1g
设置GC和OOM日志
为了便于参数调优及OOM时的问题排查，必须配置日志参数，包括：
- -XX:+PrintGCDetails 输出GC的详细日志
- -XX:+PrintGCTimeStamps 输出GC的时间戳（以基准时间的形式）
- -XX:+PrintGCDateStamps 输出GC的时间戳（以日期的形式，如 2013-05-04T21:53:59.234+0800）
- -Xloggc: GC日志文件的输出路径
- -XX:+HeapDumpOnOutOfMemoryError 发生OOM时dump堆内存
- -XX:HeapDumpPath=/home/admin/logs/java.hprof
吞吐量优先设置
- -XX:+UseParallelGC和-XX:+UseParallelOldGC：这两个收集器提供的吞吐量性能是Hotspot提供的诸多垃圾收集器中最好的。
- -XX:ParallelGCThreads=N：配置并行收集器的线程数，即：同时多少个线程一起进行垃圾回收，此值最好配置与处理器数目相等。
- -XX:+UseAdaptiveSizePolicy：设置此选项后，并行收集器会根据对象分配及存活率自动调整Eden和Survivor的比例，最优化对象老化的频率，此值建议使用并行收集器时一直打开。
响应时间优先设置
- -XX:+UseParNewGC和-XX:+UseConcMarkSweepGC
- -XX:CMSInitiatingOccupancyFraction=N
- -XX:+UseCMSInitiatingOccupancyOnly
初始大小预估
预估思路：程序运行稳定后，根据老年代和永久代占用空间大小进行预估，可通过GC日志或者可视化工具查看空间大小。
计算法则：
参数调优
新生代大小调优
调优原则：根据YGC的频率和持续时间确定新生代大小。
新生代调优分为如下两步：
1. 首先，确定应用可接受的平均延时和停顿频率；
2. 如果YGC持续的时间大于要求的平均延时，则应该减少新生代空间；如果YGC的频率大于要求的停顿频率，则应该增大新生代空间。
Eden与Survivor比例调优
调优原则： 在Survivor没有溢出的前提下，对象晋升周期越大越好。
调优过程： 如果Survivor溢出（age小的对象进入old区），说明Survivor区小，应该减小SurvivorRatio；如果对象晋升速度太快，说明Eden区小，应该增大SurvivorRatio。
CMS周期启动阈值调优
CMSInitiatingOccupancyFraction含义：老年代空间占比达到多少时开始启动CMS周期。
理想值：新生代进入老年代的速度（增长速度）等于老年代垃圾回收的速度。增长速度过快会导致老年代空间不足，触发OOM；垃圾回收速度太快，使得空间利用率不高、FGC频繁，影响吞吐量和延时。
调优过程： 如果老年代消耗的比较慢，可以在稍晚的时候启动CMS周期；如果消耗迅速，需要较早启动。
注意事项： CMSInitiatingOccupancyFraction设定的值不应该低于老年代活跃数据的占比，否则会无限循环。通用原则是至少是活跃数据占比的1.5倍。