一、前言
要想成为一名高级Java开发具备JVM调优的能力必不可少，能够根据项目实际情况进行JVM调优的前提是理解JVM原理和常用JVM参数的含义及作用，虽然《深入理解Java虚拟机》这本书已经写了很多，但是里面的提到的参数比较散乱，故写此文总结。
二、JVM参数
JVM相关参数
| 名称 | 作用 | 默认值 | 备注 |
|---|---|---|---|
| -Xms | 初始堆大小 | 物理内存的1/64(<1GB) | 默认(MinHeapFreeRatio参数可以调整)空余堆内存小于40%时， JVM就会增大堆直到-Xmx的最大限制. |
| -Xmx | 最大堆大小 | 物理内存的1/4(<1GB) | 默认(MaxHeapFreeRatio参数可以调整)空余堆内存大于70%时， JVM会减少堆直到 -Xms的最小限制 |
| -Xmn | 年轻代大小(1.4or lator) | 注意：此处的大小是（eden+ 2 survivor space).与jmap-heap中显示的 New gen是不同的。 整个堆大小=年轻代大小 + 年老代大小 + 持久代大小. 增大年轻代后,将会减小年老代大小.此值对系统性能影响较大, Sun官方推荐配置为整个堆的3/8 |
|
| -XX:NewSize | 设置年轻代大小(for 1.3/1.4) | ||
| -XX:MaxNewSize | 年轻代最大值(for 1.3/1.4) | ||
| -XX:PermSize | 设置持久代(perm gen)初始值 | 物理内存的1/64 | |
| -XX:MaxPermSize | 设置持久代最大值 | 物理内存的1/4 | |
| -Xss | 每个线程的堆栈大小 | JDK5.0以后每个线程堆栈大小为1M,以前每个线程堆栈大小为256K. 更具应用的线程所需内存大小进行 调整.在相同物理内存下, 减小这个值能生成更多的线程.但是操作系统对一个进程内的线程数还是有限制的, 不能无限生成,经验值在3000~5000左右一般小的应用， 如果栈不是很深， 应该是128k够用的 大的应用建议使用256k。这个选项对性能影响比较大，需要严格的测试。 |
|
| -XX:ThreadStackSize | Thread Stack Size | (0 means use default stack size) [Sparc: 512; Solaris x86: 320 (was 256 prior in 5.0 and earlier); Sparc 64 bit: 1024; Linux amd64: 1024 (was 0 in 5.0 and earlier); all others 0.] | |
| -XX:NewRatio | 年轻代(包括Eden和两个Survivor区)与年老代的比值(除去持久代) | 默认2 | -XX:NewRatio=4表示年轻代与年老代所占比值为1:4,年轻代占整个堆栈的1/5。Xms=Xmx并且设置了Xmn的情况下，该参数不需要进行设置。 |
| -XX:SurvivorRatio | Eden区与Survivor区的大小比值 | 8 | 设置为8,则两个Survivor区与一个Eden区的比值为2:8,一个Survivor区占整个年轻代的1/10 |
| -XX:LargePageSizeInBytes | 内存页的大小不可设置过大， 会影响Perm的大小 | =128m | |
| -XX:+UseFastAccessorMethods | 原始类型的快速优化 | ||
| -XX:+DisableExplicitGC | 关闭System.gc() | 这个参数需要严格的测试 | |
| -XX:MaxTenuringThreshold | 垃圾最大年龄 | 默认15 | 如果设置为0的话,则年轻代对象不经过Survivor区,直接进入年老代. 对于年老代比较多的应用,可以提高效率. 如果将此值设置为一个较大值,则年轻代对象会在Survivor区进行多次复制,这样可以增加对象再年轻代的存活 时间,增加在年轻代即被回收的概率该参数只有在串行GC时才有效（待考证）。 如果在Survivor空间中相同年龄所有对象大小的总和大于Survivor空间的一半，年龄大于或等于该年龄的对象就可以直接进入老年代，无需等到-XX:MaxTenuringThreshold要求的年龄。 |
| -XX:+AggressiveOpts | 加快编译 | ||
| -XX:+UseBiasedLocking | 是否启用偏向锁(since1.6) | 默认开启 | 如果程序中大多数锁都总是被不同的线程访问，关闭偏向锁可能性能更好。 |
| -Xnoclassgc | 是否要对类型回收 | ||
| -XX:SoftRefLRUPolicyMSPerMB | 每兆堆空闲空间中SoftReference的存活时间 | 1s | softly reachable objects will remain alive for some amount of time after the last time they were referenced. The default value is one second of lifetime per free megabyte in the heap |
| -XX:PretenureSizeThreshold | 对象超过多大是直接在老年代分配 | 单位字节，该参数只对新生代收集器Serial和ParNew有效， 另一种直接在旧生代分配的情况是大的数组对象,且数组中无外部引用对象. |
|
| -XX:TLABWasteTargetPercent | TLAB占eden区的百分比 | 1% | |
| -XX:+CollectGen0First | FullGC时是否先YGC | false |
并行器相关参数
| 名称 | 含义 | 默认值 | 作用 |
|---|---|---|---|
| -XX:+UseParallelGC | Full GC采用parallel MSC(此项待验证) | 选择垃圾收集器为并行收集器.此配置仅对年轻代有效.即上述配置下,年轻代使用并发收集,而年老代仍旧使用串行收集.(此项待验证) | |
| -XX:+UseParNewGC | 设置年轻代为并行收集 | 可与CMS收集同时使用，JDK5.0以上,JVM会根据系统配置自行设置,所以无需再设置此值 | |
| -XX:ParallelGCThreads | 并行收集器的线程数 | 此值最好配置与处理器数目相等 同样适用于CMS | |
| -XX:+UseParallelOldGC | 老年代垃圾收集方式为并行收集(Parallel Compacting) | since 1.6 | |
| XX:MaxGCPauseMillis | 每次年轻代垃圾回收的最长时间(最大暂停时间) | 如果无法满足此时间,JVM会自动调整年轻代大小,以满足此值. | |
| -XX:+UseAdaptiveSizePolicy | 自动选择年轻代区大小和相应的Survivor区比例 | 设置此选项后,并行收集器会自动选择年轻代区大小和相应的Survivor区比例, 以达到目标系统规定的最低响应时间或者收集频率等,此值建议使用并行收集器时,一直打开. |
|
| -XX:GCTimeRatio | 设置垃圾回收时间占程序运行时间的百分比 | 公式为1/(1+n) | |
| -XX:+ScavengeBeforeFullGC | Full GC前调用YGC | true | Do young generation GC prior to a full GC. (Introduced in 1.4.1.) |
CMS相关参数
| 名称 | 含义 | 默认值 | 作用 |
|---|---|---|---|
| -XX:+UseConcMarkSweepGC | 使用CMS收集器 | 开启后默认新生代使用ParNew收集器 | |
| -XX:+AggressiveHeap | 试图是使用大量的物理内存长时间大内存使用的优化，能检查计算资源（内存， 处理器数量） 至少需要256MB内存 大量的CPU／内存,（在1.4.1在4CPU的机器上已经显示有提升） |
||
| -XX:CMSFullGCsBeforeCompaction | 执行多少次不整理空间的Full GC之后， 下一次进入进入Full GC前进行整理 |
默认0（每次Full GC后都整理） | jdk9后废弃 |
| -XX:+CMSParallelRemarkEnabled | 降低标记停顿 | ||
| -XX+UseCMSCompactAtFullCollection | 在FULL GC的时候，对年老代的压缩 | 默认开启 | CMS是不会移动内存的，因此,这个非常容易产生碎片，导致内存不够用， 因此， 内存的压缩这个时候就会被启用。增加这个参数是个好习惯。 可能会影响性能,但是可以消除碎片 |
| -XX:+UseCMSInitiatingOccupancyOnly | 使用手动定义初始化定义开始CMS收集 | 禁止hostspot自行触发CMS GC | |
| -XX:CMSInitiatingOccupancyFraction=70 | 使用cms作为垃圾回收使用70％后开始CMS收集 | 92（since 1.6） | 为了保证不出现promotion failed(见下面介绍)错误, 该值的设置需要满足以下公式CMSInitiatingOccupancyFraction计算公式 |
| -XX:CMSInitiatingPermOccupancyFraction | 设置Perm Gen使用到达多少比率时触发 | 92 | |
| -XX:+CMSIncrementalMode | 设置为增量模式 | 不再提倡使用 | |
| -XX:+CMSClassUnloadingEnabled | 相对于并行收集器，CMS收集器默认不会对永久代进行垃圾回收。如果希望对永久代进行垃圾回收，可用设置标志-XX:+CMSClassUnloadingEnabled。 | ||
| -XX:+ExplicitGCInvokesConcurrentAndUnloadsClasses | 保证当有系统GC调用时，永久代也被包括进CMS垃圾回收的范围内 | ||
| -XX:+ExplicitGCInvokesConcurrent | 命令JVM无论什么时候调用系统GC，都执行CMS GC，而不是Full GC。(默认调用系统GC时CMS收集器会触发一次Full GC) |
G1相关参数
| 名称 | 含义 | 默认值 | 作用 |
|---|---|---|---|
| -XX:+UseG1GC | 使用G1收集器 | 主流且想更精确的把控停顿延迟（通常堆内存大于8g时使用G1才会效果更好，小堆情况CMS更佳） | |
| -XX:G1HeapRegionSize | G1的每个Region占比大小，值是 2 的幂，范围是 1 MB 到 32 MB 之间。目标是根据最小的 Java 堆大小划分出约 2048 个区域。一般不改 默认 所以g1最多支持64G的堆 | ||
| -XX:G1NewSizePercent | G1初始化的时候新生代占比大小 默认是5% | ||
| -XX:G1MaxNewSizePercent | 默认60 | 新生代最大值默认 60% 建议不要调大 采取默认 | |
| -XX:InitiatingHeapOccupancyPerecnt | 45% | G1老年代占比达到多少的适合开始Mixed gc | |
| -XX:G1MixedGCLiveThresholdPercent | 85% | 每个Region对象中存活数目的占比达到多少就不会回收 | |
| -XX:GCMixedGCCountTarget | 默认8次 | G1混合gc的回收阶段 做几次重复回收动作 |
辅助参数
| 名称 | 含义 | 默认值 | 作用 |
|---|---|---|---|
| -XX:+PrintGC | 输出形式: [GC 118250K->113543K(130112K), 0.0094143 secs] [Full GC 121376K->10414K(130112K), 0.0650971 secs] |
||
| -XX:+PrintGCDetails | 输出形式: [GC [DefNew: 8614K->781K(9088K), 0.0123035 secs] 118250K->113543K(130112K), 0.0124633 secs] [GC [DefNew: 8614K->8614K(9088K), 0.0000665 secs][Tenured: 112761K->10414K(121024K), 0.0433488 secs] 121376K->10414K(130112K), 0.0436268 secs] |
||
| -XX:+PrintGCTimeStamps | |||
| -XX:+PrintGC:PrintGCTimeStamps | 可与-XX:+PrintGC -XX:+PrintGCDetails混合使用, 输出形式:11.851: [GC 98328K->93620K(130112K), 0.0082960 secs] |
||
| -XX:+PrintGCApplicationStoppedTime | 打印垃圾回收期间程序暂停的时间.可与上面混合使用 | 输出形式:Total time for which application threads were stopped: 0.0468229 seconds | |
| -XX:+PrintGCApplicationConcurrentTime | 打印每次垃圾回收前,程序未中断的执行时间.可与上面混合使用 | 输出形式:Application time: 0.5291524 seconds | |
| -XX:+PrintHeapAtGC | 打印GC前后的详细堆栈信息 | ||
| -Xloggc:filename | 把相关日志信息记录到文件以便分析.与上面几个配合使用 | ||
| -XX:+PrintClassHistogram | garbage collects before printing the histogram. | ||
| -XX:+PrintTLAB | 查看TLAB空间的使用情况 | ||
| -XX:+PrintTenuringDistribution | 查看每次minor GC后新的存活周期的阈值 | Desired survivor size 1048576 bytes, new threshold 7 (max 15) new threshold 7即标识新的存活周期的阈值为7。 |
三、调优策略
JVM调优一般来说要根据实际情况，不断调整参数来找到最佳的参数设置，但是有些经验是通用的。
经验：
- XMX和XMS设置一样大，MaxPermSize和MinPermSize设置一样大，这样可以减轻伸缩堆大小带来的压力。
- 用64位操作系统，Linux下64位的jdk比32位jdk要慢一些，但是吃得内存更多，吞吐量更大
- 使用CMS的好处是用尽量少的新生代，经验值是128M－256M， 然后老生代利用CMS并行收集， 这样能保证系统低延迟的吞吐效率。 实际上cms的收集停顿时间非常的短，2G的内存， 大约20－80ms的应用程序停顿时间
- 系统停顿的时候可能是GC的问题也可能是程序的问题，多用jmap和jstack查看，或者killall -3 java，然后查看java控制台日志，能看出很多问题。
- 仔细了解自己的应用，如果用了缓存，那么年老代应该大一些，缓存的HashMap不应该无限制长，建议采用LRU算法的Map做缓存，LRUMap的最大长度也要根据实际情况设定。
- 采用并发回收时，年轻代小一点，年老代要大，因为年老大用的是并发回收，即使时间长点也不会影响其他程序继续运行，网站不会停顿。
- 一般避免年轻代设置过小，过小会导致：1.YGC次数更加频繁 2.可能导致YGC对象直接进入老年代,如果此时老年代满了,会触发FGC.
使用CMS有几个问题需要注意：
promotion failed
- 问题原因：
该问题是在进行Minor GC时，Survivor Space放不下，对象只能放入老年代，而此时老年代也放不下造成的。（promotion failed时老年代CMS还没有机会进行回收，又放不下转移到老年代的对象，因此会出现下一个问题concurrent mode failure，需要stop-the-wold 降级为GC-Serail Old）。
- 解决方案：
去掉Survivor空间，设置-XX:SurvivorRatio=65536 -XX:MaxTenuringThreshold=0即可，存活的对象直接进去老年代。
concurrent mode failure
- 解决方案：
通过参数-XX:CMSInitiatingOccupancyFraction设置合理的CMS的触发百分比，保证提前触发Full GC避免老年代空间不够的问题。
CMSInitiatingOccupancyFraction的计算公式：
上面介绍了promontion faild产生的原因是EDEN空间不足的情况下将EDEN与From survivor中的存活对象存入To survivor区时,To survivor区的空间不足，再次晋升到old gen区，而old gen区内存也不够的情况下产生了promontion faild从而导致full gc.那可以推断出：eden+from survivor < old gen区剩余内存时，不会出现promontion faild的情况，即：
(Xmx-Xmn)*(1-CMSInitiatingOccupancyFraction/100)>=(Xmn-Xmn/(SurvivorRatior+2)) 进而推断出：
CMSInitiatingOccupancyFraction <=((Xmx-Xmn)-(Xmn-Xmn/(SurvivorRatior+2)))/(Xmx-Xmn)*100
例如：
当xmx=128 xmn=36 SurvivorRatior=1时 CMSInitiatingOccupancyFraction<=((128.0-36)-(36-36/(1+2)))/(128-36)*100 =73.913
当xmx=128 xmn=24 SurvivorRatior=1时 CMSInitiatingOccupancyFraction<=((128.0-24)-(24-24/(1+2)))/(128-24)*100=84.615…
当xmx=3000 xmn=600 SurvivorRatior=1时 CMSInitiatingOccupancyFraction<=((3000.0-600)-(600-600/(1+2)))/(3000-600)*100=83.33
空间碎片问题
- 问题原因：
CMS是基于“标记-清除”算法的收集器，如果GC后有大量的空间碎片产生，空间碎片很多后分配大对象就会出现老年代还有很多空间但是无法找到连续的空间来分配，从而不得不触发Full GC。
- 解决方案：
-XX:UseCMSCompactAtFullCollection -XX:CMSFullGCBeforeCompaction=0，设置每次Full GC之后都进行碎片整理。
网上某牛人的配置：
$JAVA_ARGS
.=
"
-Dresin.home=$SERVER_ROOT
-server
-Xms6000M
-Xmx6000M
-Xmn500M
-XX:PermSize=500M
-XX:MaxPermSize=500M
-XX:SurvivorRatio=65536
-XX:MaxTenuringThreshold=0
-Xnoclassgc
-XX:+DisableExplicitGC
-XX:+UseParNewGC
-XX:+UseConcMarkSweepGC
-XX:+UseCMSCompactAtFullCollection
-XX:CMSFullGCsBeforeCompaction=0
-XX:+CMSClassUnloadingEnabled
-XX:-CMSParallelRemarkEnabled
-XX:CMSInitiatingOccupancyFraction=90
-XX:SoftRefLRUPolicyMSPerMB=0
-XX:+PrintClassHistogram
-XX:+PrintGCDetails
-XX:+PrintGCTimeStamps
-XX:+PrintHeapAtGC
-Xloggc:log/gc.log
";
补上一个JVM参数检查优化的网站：https://console.perfma.com/
示例
参考：
《JVM参数设置、分析》
《关于Jvm知识看这一篇就够了》
《深入理解Java虚拟机》第三版