1. 概述
之前的文章中介绍了 jvm 内存管理和垃圾收集的相关内容，结合这些理论知识，通过合理设置参数才能将系统的性能得以提升。
2. JVM 主要参数
2.1. 基本的设置参数
JVM 设置参数的主要含义
参数名称 | 含义 | 默认值 | 说明 |
|---|---|---|---|
-Xms | 最小堆大小 | 物理内存的 1/64(<1GB) | 空闲堆内存小于40%（通过 MinHeapFreeRatio 参数可调整该阈值）时，jvm 会增大堆直到 -Xmx |
-Xmx | 最大堆大小 | 物理内存的 1/4(<1GB) | 空闲堆内存大于70%（通过 MaxHeapFreeRatio 参数可以调整该阈值）时，jvm 会减小堆直到 -Xms |
-Xmn | 新生代大小 | 无 | 指 Eden 与两个 Survivor 空间之和，Sun 官方推荐配置为整个堆的 3/8 |
-XX:PermSize | 方法区（永久代）大小 | 物理内存的 1/64 | - |
-Xss | 每个线程的堆栈大小 | 1M | - |
-XX:ThreadStackSize | 线程堆栈大小 | 1M | 主线程以 -Xss 设置为主，其他线程以该设置为主，一般采用默认值即可 |
-XX:NewRadio | 新生代与老年代大小的比值 | 无 | Xms=Xmx并且设置了Xmn的情况下，该参数不需要进行设置 |
-XX:SurvivorRatio | Eden 区域 Survivor 区大小的比值 | 无 | - |
-XX:LargePageSizeInBytes | 内存页大小 | 128M | 不可设置过大 |
-XX: UseFastAccessorMethods | 是否使用原始类型的快速优化 | 无 | - |
-XX: DisableExplicitGC | 是否关闭 System.gc() | 无 | - |
-XX:MaxTenuringThreshold | 垃圾最大年龄 | 无 | N 次没有被回收的新生代资源自动放入老年代，只有使用串行GC时才有效 |
-XX:MaxGCPauseMillis | 最大停顿时间 | - | 每次年轻代垃圾收集的最长时间 |
-Xnoclassgc | 金庸垃圾回收 | 无 | - |
-XX:SoftRefLRUPolicyMSPerMB | 没M堆内存中软引用存活时间 | 1s | - |
-XX:PretenureSizeThreshold | 对象超过多大自动在老年代分配 | 0 | 采用 Parallel Scavenge GC 时无效 |
-XX:TLABWasteTargetPercent | TLAB 占 eden 区的百分比 | 1% | - |
-XX: CollectGen0First | FullGC时是否先YGC | false | - |
2.2. 并行收集相关的参数
JVM 并行GC的设置参数
参数名称 | 含义 | 默认值 | 说明 |
|---|---|---|---|
-XX: UseParGC | 使用 ParNew 收集器进行新生代收集 | false | 与 -XX: UseConcMarkSweepGC 相同 |
-XX:ParallelGCThreads | 并行收集线程数 | - | 指定并行 GC 下的垃圾收集线程数，最好配置为与 CPU 数相等 |
-XX: UseParallelOldGC | 设置老年代收集器为 Parallel Old | JDK1.6 起开始提供 | - |
-XX: UseAdaptiveSizePolicy | 自动选择年轻代大小及 Survivor 比例 | false | 建议在使用并行收集器一直打开 |
-XX:GCTimeRatio | 设置垃圾回收时间占用程序运行时间百分比 | 无 | 大于 0 小于 100，使用 Parallel Scavenge 时设置 |
-XX: UseAdaptiveSizePolicy | 是否自动根据当前系统情况决定最大吞吐量的限制 | false | 使用 Parallel Scavenge 时设置 |
-XX: ScavengeBeforeFullGC | Full GC前调用YGC | true | - |
2.3. CMS 相关参数
JVM CMS GC 的设置参数
参数名称 | 含义 | 默认值 | 说明 |
|---|---|---|---|
-XX: UseConcMarkSweepGC | 启用 CMS GC | false | - |
-XX:CMSFullGCsBeforeCompaction | 运行多少次 GC 后进行一次内存压缩（碎片整理） | - | - |
-XX: CMSParallelRemarkEnabled | 降低标记停顿 | false | - |
-XX UseCMSCompactAtFullCollection | 是否启用内存压缩（碎片整理） | - | 建议开启 |
-XX: UseCMSInitiatingOccupancyOnly | 手动触发 CMS | false | 禁止 HotSpot 自动触发 CMS GC |
-XX:CMSInitiatingOccupancyFraction | GC 触发阈值（百分比） | 1.5为68，1.6为92 | 内存使用达到阈值则开始 GC，设置过大会有可能造成失败而进行 full GC |
-XX: CMSIncrementalMode | 设置为增量模式 | false | 运用于单CPU下，在 CMS 运行途中暂停，继续运行用户线程，下次增量 GC |
-XX:CMSClassUnloadingEnabled | 垃圾回收清理方法区时移除不再使用的 classes | - | - |
-XX: CMSPermGenSweepingEnabled | 是否清理方法区（永久代） | - | 默认不清理 |
3. 设置规则
3.1. 年轻代大小选择
1. 响应时间优先的应用 — 尽可能增大年轻代大小，这也意味着老年代的大小会相对减少，因此同时要减少到达老年代的对象 2. 吞吐量优先应用 — 尽可能增大年轻代，可以选择并行垃圾收集，适合 8CPU 以上应用
无论如何，谨记不能将新生代设置过小，否则会造成新生代 GC 频繁，甚至让新生代对象直接进入老年代，从而触发 full GC。
3.2. 老年代大小选择
1. 响应时间优先的应用 — 通常老年代使用 CMS 进行并发收集，所以老年代不能设计过小，否则会因为内存过多造成频繁 full GC；如果设计过大，则需要较长的收集，因此需要结合并发收集信息、持久化并发收集次数、传统GC信息、年轻代和老年代的时间比例考虑具体的内存大小 2. 吞吐量优先应用 — 这样的应用通常需要大年轻代 小老年代，这样可以尽可能回收大部分短期对象，减少中期对象，而老年代存放长期存活对象
3.3. 老年代的内存碎片问题
如果使用 CMS 作为老年代收集器，那么由于他采取的标记清除算法，通常会造成碎片，如果最终空间不足，则会触发一次 full GC。 针对这种情况，需要进行如下配置： 1. -XX: UseCMSCompactAtFullCollection — 使用并发收集器时，开启对年老代的压缩 2. -XX:CMSFullGCsBeforeCompaction=0 — 上面配置开启的情况下，这里设置多少次Full GC后，对年老代进行压缩
3.4. 其他事项
1. linux 64 位操作系统中，jdk 消耗内存更多，执行速度更慢，但吞吐量更大 2. XMX 和 XMS 设置一样大，MaxPermSize 和 MinPermSize 设置一样大，这样可以减轻伸缩堆大小带来的压力 3. 使用CMS的好处是用尽量少的新生代，经验值是128M－256M， 然后老生代利用CMS并行收集， 这样能保证系统低延迟的吞吐效率。 实际上cms的收集停顿时间非常的短，2G的内存， 大约20－80ms的应用程序停顿时间 4. 系统停顿的时候可能是GC的问题也可能是程序的问题，多用jmap和jstack查看，或者killall -3 java，然后查看java控制台日志，能看出很多问题。 5. 如果用了缓存，那么年老代应该大一些 6. 采用并发回收时，年轻代小一点，年老代要大，因为年老大用的是并发回收，即使时间长点也不会影响其他程序继续运行，网站不会停顿
4. 问题分析 — promotion failed
产生 promotion failed 可能是两个原因引起的： 1. 新生代的 survivor 不足，年轻代中很多对象等待放入 survior 内存，致使 Survivor 空间不足，这些内存被放入老年代 2. 老年代没有足够的内存接纳来自年轻代的对象
解决这个问题，就要从这两个原因着手： 1. 增大 Survivor 区域大小，设置 -XX:SurvivorRatio=1 2. 降低 CMSInitiatingOccupancyFraction（如设置为 70），让老年代在较低阈值时被回收
可以推断出：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。
