7.性能调优 - 7.1 JVM参数 - 《JAVA》

JVM参数的含义
并行收集器相关参数
CMS相关参数
辅助信息参数
常用参数设置大小
GC日志详解
- 如何分析GC日志
- GC日志分析工具

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是不同的。

整个堆大小=年轻代大小 + 年老代大小 + 持久代大小.

一般小的应用，如果栈不是很深，应该是128k够用的大的应用建议使用256k。这个选项对性能影响比较大，需要严格的测试。（校长）

和threadstacksize选项解释很类似,官方文档似乎没有解释,在论坛中有这样一句话:””

-Xss is translated in a VM flag named ThreadStackSize”

一般设置这个值就可以了。 | | -
XX:
Thread
StackSize | 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区)与年老代的比值(除去持久代) | | -XX:NewRatio=4表示年轻代与年老代所占比值为1:4,年轻代占整个堆栈的1/5

并行收集器相关参数

| -XX:+UseParallelGC | Full GC采用parallel MSC

(此项待验证) | | 选择垃圾收集器为并行收集器.此配置仅对年轻代有效.即上述配置下,年轻代使用并发收集,而年老代仍旧使用串行收集.(此项待验证) | | —- | —- | —- | —- | | -XX:+UseParNewGC | 设置年轻代为并行收集 | | 可与CMS收集同时使用

CMS相关参数

-XX:+UseConcMarkSweepGC	使用CMS内存收集		测试中配置这个以后,-XX:NewRatio=4的配置失效了,原因不明.所以,此时年轻代大小最好用-Xmn设置.???
-XX:+AggressiveHeap			试图是使用大量的物理内存

长时间大内存使用的优化，能检查计算资源（内存，处理器数量）

至少需要256MB内存

辅助信息参数

-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混合使用

常用参数设置大小

 -Xms4096m  //初始堆大小
-Xmx4096m  //最大堆大小
-Xmn1536m //新生代大小 eden + from + to
-Xss512K  //线程大小
-XX:NewRatio=2  //新生代和老年代的比例
-XX:MaxPermSize=64m   //持久代最大值
-XX:PermSize=16m  //持久代初始值
-XX:SurvivorRatio=8  // eden 区和survivor区的比例
-verbose:gc  
-Xloggc:gc.log  //输出gc日志文件
-XX:+UseGCLogFileRotation  //使用log文件循环输出
-XX:NumberOfGCLogFiles=1  //循环输出文件数量
-XX:GCLogFileSize=8k //日志文件大小限制
-XX:+PrintGCDateStamps //gc日志打印时间
-XX:+PrintTenuringDistribution            //查看每次minor GC后新的存活周期的阈值
-XX:+PrintGCDetails //输出gc明细
-XX:+PrintGCApplicationStoppedTime //输出gc造成应用停顿的时间
-XX:+PrintReferenceGC //输出堆内对象引用收集时间
-XX:+PrintHeapAtGC //输出gc前后堆占用情况
-XX:+UseParallelGC  //年轻代并行GC，标记-清除
-XX:+UseParallelOldGC //老年代并行GC，标记-清除
-XX:ParallelGCThreads=23 //并行GC线程数， cpu<=8?cpu:5*cpu/8+3
-XX:+UseAdaptiveSizePolicy //默认，自动调整年轻代各区大小及晋升年龄
-XX:MaxGCPauseMillis=15 //每次GC最大停顿时间,单位为毫秒
-XX:+UseParNewGC  //Serial多线程版
-XX:+UseConcMarkSweepGC  //CMS old gc
-XX:+UseCMSCompactAtFullCollection  //FullGC后进行内存碎片整理压缩
-XX:CMSFullGCsBeforeCompaction=n  //n次FullGC后执行内存整理
-XX:+CMSParallelRemarkEnabled  //启用并行重新标记,只适用ParNewGC
-XX:CMSInitiatingOccupancyFraction=80             //cms作为垃圾回收是，回收比例80%
-XX:ParallelGCThreads=23 //并行GC线程数，cpu<=8?cpu:5*cpu/8+3
-XX:-UseSerialGC //默认不启用，client使用时启用
-XX:+UseG1GC //启用G1收集器
-XX:-UseAdaptiveSizePolicy //默认，不自动调整各区大小及晋升年龄
-XX:PretenureSizeThreshold=2097152 //直接晋升到老年代的对象大小
-XX:MaxTenuringThreshold=15(default) //晋升到老年代的对象年龄，PSGen无效
-XX:-DisableExplicitGC //禁止在运行期显式地调用?System.gc() 
-XX:+HeapDumpOnOutOfMemoryError  //在OOM时输出堆内存快照
-XX:HeapDumpPath=./java_pid<pid>.hprof  //堆内存快照的存储路径 
-XX:+CMSScavengeBeforeRemark //执行CMS重新标记之前，尝试执行一此MinorGC
-XX:+CMSPermGenSweepingEnabled //开启永久代的并发垃圾收集

使用IDEA，选择Run->Edit Configurations，然后点击左边的+号，选择Application，出现如下界面，加入JVM参数

GC日志详解

对于java应用我们可以通过一些配置把程序运行过程中的gc日志全部打印出来，
然后分析gc日志得到关键性指标，分析GC原因，调优JVM参数。
打印GC日志方法，在JVM参数里增加参数，%t 代表时间

-Xloggc:./gc-%t.log -XX:+PrintGCDetails -XX:+PrintGCDateStamps  
-XX:+PrintGCTimeStamps -XX:+PrintGCCause  
-XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=10 -XX:GCLogFileSize=100M

Tomcat则直接加在JAVA_OPTS变量里。

如何分析GC日志

运行程序加上对应gc日志

java -jar -Xloggc:./gc-%t.log -XX:+PrintGCDetails -XX:+PrintGCDateStamps  -XX:+PrintGCTimeStamps -XX:+PrintGCCause  
-XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=10 -XX:GCLogFileSize=100M microservice-eureka-server.jar

下图中是我截取的JVM刚启动的一部分GC日志

我们可以看到图中第一行红框，是项目的配置参数。这里不仅配置了打印GC日志，还有相关的VM内存参数。
第二行红框中的是在这个GC时间点发生GC之后相关GC情况。
1、对于2.909： 这是从jvm启动开始计算到这次GC经过的时间，前面还有具体的发生时间日期。
2、Full GC(Metadata GC Threshold)指这是一次full gc，括号里是gc的原因， PSYoungGen是年轻代的GC，ParOldGen是老年代的GC，Metaspace是元空间的GC
3、6160K->0K(141824K)，这三个数字分别对应GC之前占用年轻代的大小，GC之后年轻代占用，以及整个年轻代的大小。
4、112K->6056K(95744K)，这三个数字分别对应GC之前占用老年代的大小，GC之后老年代占用，以及整个老年代的大小。
5、6272K->6056K(237568K)，这三个数字分别对应GC之前占用堆内存的大小，GC之后堆内存占用，以及整个堆内存的大小。
6、20516K->20516K(1069056K)，这三个数字分别对应GC之前占用元空间内存的大小，GC之后元空间内存占用，以及整个元空间内存的大小。
7、0.0209707是该时间点GC总耗费时间。
从日志可以发现几次fullgc都是由于元空间不够导致的，所以我们可以将元空间调大点

java -jar -Xloggc:./gc-adjust-%t.log -XX:MetaspaceSize=256M -XX:MaxMetaspaceSize=256M -XX:+PrintGCDetails -XX:+PrintGCDateStamps  
-XX:+PrintGCTimeStamps -XX:+PrintGCCause  -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=10 -XX:GCLogFileSize=100M 
microservice-eureka-server.jar

调整完我们再看下gc日志发现已经没有因为元空间不够导致的fullgc了

对于CMS和G1收集器的日志会有一点不一样，也可以试着打印下对应的gc日志分析下，可以发现gc日志里面的gc步骤跟我们之前讲过的步骤是类似的

public class HeapTest {

    byte[] a = new byte[1024 * 100];  //100KB

    public static void main(String[] args) throws InterruptedException {
        ArrayList<HeapTest> heapTests = new ArrayList<>();
        while (true) {
            heapTests.add(new HeapTest());
            Thread.sleep(10);
        }
    }
}

CMS

-Xloggc:d:/gc-cms-%t.log -Xms50M -Xmx50M -XX:MetaspaceSize=256M -XX:MaxMetaspaceSize=256M -XX:+PrintGCDetails -XX:+PrintGCDateStamps  
 -XX:+PrintGCTimeStamps -XX:+PrintGCCause  -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=10 -XX:GCLogFileSize=100M 
 -XX:+UseParNewGC -XX:+UseConcMarkSweepGC

-Xloggc:d:/gc-g1-%t.log -Xms50M -Xmx50M -XX:MetaspaceSize=256M -XX:MaxMetaspaceSize=256M -XX:+PrintGCDetails -XX:+PrintGCDateStamps  
 -XX:+PrintGCTimeStamps -XX:+PrintGCCaus -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=10 -XX:GCLogFileSize=100M -XX:+UseG1GC

GC日志分析工具

上面的这些参数，能够帮我们查看分析GC的垃圾收集情况。但是如果GC日志很多很多，成千上万行。
就算一目十行，看完了，脑子也是一片空白。所以我们可以借助一些功能来帮助我们分析，这里推荐一个gceasy(https://gceasy.io)，可以上传gc文件，然后他会利用可视化的界面来展现GC情况。具体下图所示

上图我们可以看到年轻代，老年代，以及永久代的内存分配，和最大使用情况。

上图我们可以看到堆内存在GC之前和之后的变化，以及其他信息。
这个工具还提供基于机器学习的JVM智能优化建议，当然现在这个功能需要付费