在生产系统中,高吞吐和低延迟一直都是JVM调优的最终目标,但这两者恰恰又是相悖的,鱼和熊掌不可兼得,所以在调优之前要清楚舍谁而取谁。一般计算任务和组件服务会偏向高吞吐,而web展示则偏向低延迟才会带来更好的用户体验。

本文从性能和经验上来分享一下JVM参数的设置。

调优之前可以先用-XX:+PrintFlagsFinal来查看虚拟机是否默认开启某参数,不同版本的JDK可能虚拟机默认开启的参数也略有不同,新学习一条神奇的参数的时候可以先去查找一下参数是否默认开启了。

$ java -server -XX:+PrintCommandLineFlags |grep XXXXXXX

也可以通过jinfo口令 jinfo -flags [pid]来查看

GC策略

目前来看还是CMS当道,吞吐率和响应时间阔以兼顾,G1嘛,鸡丸鸡丸,至今并没有展现出one的实力,不过据贵里某P8讲G1在大堆(20G+)下表现更突出,停顿会显著降低,可能之后随着高内存越来越经济和普及,G1才能名副其实的称为鸡one。

废话少说,

-XX:+UseConcMarkSweepGC

设置CMS做为垃圾收集,CMS开启后默认的新生代回收是ParNew,如果CMS出现“Concurrent Mode Failure”了还会启用Serial Old做备胎。


-XX:CMSInitiatingOccupancyFraction=75

默认值是68,这个可以根据实际调优目标来调整,这个参数就比较应开始提到的,调优目标是降低延迟还是提高吞吐,如果是为了降低单次GC延迟,那么这个值阔以再往低了调一些,不过调的太高可能导致老年代剩余空间不够招呼并发收集产生的浮动垃圾而频繁的触发Full GC。


-XX:+UseCMSInitiatingOccupancyOnly

使用CMS的话这个参数一定要加上,一定要加上,一定要加上,重要的事情说三遍,否则虚拟机后面还是会自作聪明的自己计算上个参数的比值。


-XX:MaxTenuringThreshold=5

默认15,这个值是设置新生代对象存活了多少次young GC后可以进入老年代,值设的高的话可以使老年代增长缓慢,但YGC的次数会明显增多,如果清楚YGC的执行频率和大多数对象的最长生命周期,这个值可以设低些,让那些对象早点进入老年代。
可以用-XX:+PrintTenuringDistribution来观察一段时间,然后调整合适的值。

ps:有一种野路子是此值设为0,新生代GC次数少,速度快,就是老年代GC会更加频繁一些,不过也最大利用了并发GC。不过我没在生产这么搞过,效果有待验证。


-XX:+ExplicitGCInvokesConcurrent

这个参数是用来代替,-XX:DisableExplicitGC的,NIO许多地方会显示的调用System.gc()来触发一次Full GC。许多时候别的地方优化一万点都赔不起这儿调上几次的。ExplicitGCInvokesConcurrent这个参数是配合CMS使用的,开启后System.gc()还是会触发Full GC,不过并不是一个完全的stop-the-world的Full GC,而是并发的CMS GC。


内存设置

现在线上业务系统基本物理内存都是够用的,不过物尽其用,我们调优就是争取让每M空间都发挥出最大的作用。内存的设置还是最直观见效的。

-Xmx500m ,-Xms500m

最大堆内存和最小堆内存,这两个值要设的一致,避免虚拟机还要动态的计算分配内存空间。
PS:堆也不是越大越好,大堆带来的后果就是单次GC会较长。


-Xmn250m

新生代大小,非G1收集器可以设置这个值,G1的官方建议是不要显示分配新生代和老年代空间大小,因为G1会通过网格化内存来动态分配new/old区,官方认为不设置new size是最佳实践。


-Xss2m

每个线程的栈空间大小,默认值是1m,一般不需要设置,除非有递归方法存在可能会爆栈。


-XX:PermSize=128m,-XX:MaxPermSize=256m

JDK8之前永久代的空间设置,Spring框架了大量依赖AOP的实现都用的动态代理生成字节码,所以设个最大值求保险。
不过JDK8之后取消了永久代,改为元空间(MetaSpace),这块属于本地内存,理论上可以利用系统剩余的所有内存,不过跑了多个实例的话还是要设置一下为妙:

-XX:MetaspaceSize=128m,-XX:MaxMetaspaceSize=256m


-XX:MaxDirectMemorySize=128m

这个属于对外内存,可以合理控制大小。Heap区总内存减去一个Survivor区的大小,不宜过大,否则可能heap size + Direct Memory Size把物理内存耗光。


-XX:SurvivorRatio=7

默认是8,新生代中Eden与Survivor的比值,过大的话可能Survivor存不下临时对象而频繁触发分配担保。可以根据GC日志看实际情况。


PS:
关于内存大小的设置完全要根据各个机器和应用自身的情况来设置。
可以通过jstat -gc [pid] 2000 30,每2s输出一次一共输出30次内存情况,看看各个区域增长的速度,最大空间等数据来修改内存设置。


监控输出

监控参数还是需要的,不然有时候线上偶尔OOM了真的不好重现。


-XX:+HeapDumpOnOutOfMemoryError,-XX:HeapDumpPath={path}

OOM的时候会输出dump快照到{path}目录,只需要指向目录,文件名JVM会保持唯一性。


-XX:+PrintGCDetails,-Xloggc:logs/gc.log,-XX:+PrintGCTimeStamps,-XX:+PrintGCDateStamps

打印GC详细记录,-XX:+PrintGC 这个口令是简单GC日志,为了更容易定位问题,我们开启Details模式,-Xloggc是把gc日志输出到指定文件。
-XX:+PrintGCTimeStamps显示的时间代表JVM启动至记录日志的时间。
-XX:+PrintGCDateStamps则会添加上每行信息的绝对日期。
其实开启了-Xloggc的话会隐式的开启-XX:+PrintGCTimeStamps,不过为了防止各版本JVM改动差异,还是显示的设置出来保险。


-XX:-OmitStackTraceInFastThrow

这是个比较容易被忽略的参数,而没有经验的话又往往很难定位到原因。
JDK5之后JVM对异常做了一个优化,对于一些频繁抛出的异常,JIT重新编译后会抛出没有堆栈信息的异常,-server模式下是默认开启的,因此在频繁抛出某个异常一段时间后,该优化开始起作用,即只抛出没有堆栈的异常信息。
但由于该优化是JIT编译后才启用的,所以开始该异常的抛出是有完整堆栈信息的,但运行一段时间可能发现没有任何堆栈信息,很难定位,初次遇到很容易摸不到头脑。
可以使用-XX:-OmitStackTraceInFastThrow来关闭该项优化

 

补充知识点:

 

假设你是一个普通的 Java 对象,你出生在 Eden 区,在 Eden 区有许多和你差不多的小兄弟、小姐妹,可以把 Eden 区当成幼儿园,在这个幼儿园里大家玩了很长时间。Eden 区不能无休止地放你们在里面,所以当年纪稍大,你就要被送到学校去上学,这里假设从小学到高中都称为 Survivor 区。开始的时候你在 Survivor 区里面划分出来的的“From”区,读到高年级了,就进了 Survivor 区的“To”区,中间由于学习成绩不稳定,还经常来回折腾。直到你 18 岁的时候,高中毕业了,该去社会上闯闯了。于是你就去了年老代,年老代里面人也很多。在年老代里,你生活了 20 年 (每次 GC 加一岁),最后寿终正寝,被 GC 回收。有一点没有提,你在年老代遇到了一个同学,他的名字叫爱德华 (慕光之城里的帅哥吸血鬼),他以及他的家族永远不会死,那么他们就生活在永生代!

线上在用的配置:(java8)

nohup java -jar -server -Xms2G -Xmx2G -XX:+UseG1GC -XX:MaxGCPauseMillis=200 -XX:+UnlockExperimentalVMOptions -XX:G1NewSizePercent=20 -XX:G1MaxNewSizePercent=30 -XX:+DisableExplicitGC -XX:+PrintGC -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=./logs/oom-error_11996.log -Xloggc:gc-error_11996.log report-1.0.jar > run.log &

 

一些监测JVM的命令

  • jps

列出正在运行的虚拟机进程

  • jstat

监视虚拟机运行状态信息

  • jmap

生成堆存储快照

  • jstack

生成虚拟机当前时刻的线程快照,帮助定位线程出现长时间停顿的原因

一、JVM调优知识背景简介

二、JVM调优参数简介

三、JVM调优目标

四、JVM调优经验

结束语

前言

本次分享探讨的JVM调优是指server端运行的JVM调优,适应版本为[1.6– 1.7], 不涉及最新的1.8版本。

假设线程池、连接池、程序代码等都已经做过优化,效果(系统吞吐量、响应性能)仍然不理想,我们就可以考虑JVM调优了。

一、 JVM调优知识背景简介

1、堆与栈的概念

堆和栈是程序运行的关键:栈是运行时的单位,而堆是存储的单位。

栈解决程序的运行问题,即程序如何执行,或者说如何处理数据;堆解决的是数据存储的问题,即数据怎么

放、放在哪儿。

在Java中一个线程就会相应有一个线程栈与之对应,而堆则是所有线程共享的。

栈存储的信息都是跟当前线程(或程序)相关信息的,包括:局部变量、程序运行状态、方法返回值等等。

堆只负责存储对象信息
简单来说:堆中存的是对象,栈中存的是基本数据类型和堆中对象的引用。

2、堆模型

虚拟机中共划分为三个代:

年轻代(Young Generation:用来存放JVM刚分配的Java对象。

年老代(Old Generation:年轻代中经过垃圾回收没有回收掉的对象将被Copy到年老代。

持久代(PermGeneration:存放Class、Method元信息,其大小跟项目的规模、类、方法的量有关。

如下图所示:

3、堆内存分配策略

1.对象优先在Eden分配

如果Eden区不足分配对象,会做一个minorgc,回收内存,尝试分配对象,如果依然不足分配,才分配到Old区。

2.大对象直接进入老年代

大对象是指需要大量连续内存空间的Java对象,最典型的大对象就是那种很长的字符串及数组,虚拟机提供了一个-XX:PretenureSizeThreshold参数,令大于这个设置值的对象直接在老年代中分配。这样做的目的是避免在Eden区及两个Survivor区之间发生大量的内存拷贝(新生代采用复制算法收集内存)。PretenureSizeThreshold参数只对Serial和ParNew两款收集器有效。

3.长期存活的对象将进入老年代
在经历了多次的Minor GC后仍然存活:在触发了Minor GC后,存活对象被存入Survivor区在经历了多次MinorGC之后,如果仍然存活的话,则该对象被晋升到Old区。虚拟机给每个对象定义了一个对象年龄(Age)计数器。如果对象在Eden出生并经过第一次MinorGC后仍然存活,并且能被Survivor容纳的话,将被移动到Survivor空间中,并将对象年龄设为1。对象在Survivor区中每熬过一次MinorGC,年龄就增加1岁,当它的年龄增加到一定程度(默认为15岁)时,就会被晋升到老年代中。对象晋升老年代的年龄阈值,可以通过参数-XX:MaxTenuringThreshold来设置。

4.动态对象年龄判定

为了能更好地适应不同程序的内存状况,虚拟机并不总是要求对象的年龄必须达到MaxTenuringThreshold才能晋升老年代,如果在Survivor空间中相同年龄所有对象大小的总和大于Survivor空间的一半,年龄大于或等于该年龄的对象就可以直接进入老年代,无须等到MaxTenuringThreshold中要求的年龄。

5.MinorGCSurvivor空间不足就直接放入Old
6.空间分配担保

在发生MinorGC时,虚拟机会检测之前每次晋升到老年代的平均大小是否大于老年代的剩余空间大小,如果大于,则改为直接进行一次Full GC。如果小于,则查看HandlePromotionFailure设置是否允许担保失败;如果允许,那只会进行Minor GC;如果不允许,则也要改为进行一次Full GC。大部分情况下都还是会将HandlePromotionFailure开关打开,避免FullGC过于频繁。

4、JVM垃圾回收器简介Java 语言的一大特点就是可以进行自动垃圾回收处理,而无需开发人员过于关注内存资源的释放情况。自动垃圾收集虽然大大减轻了开发人员的工作量,但是也增加了软件系统的负担。

垃圾回收器常用的算法:

1.引用计数法 (Reference Counting)
2.标记-清除算法 (Mark-Sweep)
3.复制算法 (Copying)
4.标记-压缩算法 (Mark-Compact)
5.增量算法 (Incremental Collecting)
6.分代 (Generational Collecting)

从不同角度分析垃圾收集器,可以将其分为不同的类型。

1.按线程数分,可以分为串行垃圾回收器和并行垃圾回收器;
2.按照工作模式分,可以分为并发式垃圾回收器和独占式垃圾回收器;
3.按碎片处理方式可分为压缩式垃圾回收器和非压缩式垃圾回收器;
4.按工作的内存区间,又可分为新生代垃圾回收器和老年代垃圾回收器。

JVM默认的垃圾回收器是Parallel GC垃圾回收器,搭配为ParallelGC + ParallelOldGC ,满足一般场景下JVM垃圾回收。

可以用以下指标评价一个垃圾处理器的好坏:

1.吞吐量;
2.垃圾回收器负载;
3.停顿时间;
4.垃圾回收频率;
5.反应时间;
6.堆分配。

5、 CMS(Concurrent Mark-Sweep)垃圾回收器简介

CMS(Concurrent Mark-Sweep)是以牺牲吞吐量为代价来获得最短回收停顿时间的垃圾回收器。对于要求服务器响应速度的应用上,这种垃圾回收器非常适合。在启动JVM参数加上-XX:+UseConcMarkSweepGC ,这个参数表示对于老年代的回收采用CMS。CMS采用的基础算法是:标记—清除。

CMS适应场景:
1. 相对较多存活时间较长的对象(老年代比较大);

2. 服务器响应性能要求高;

6、 JVM GC组合方式

二、 JVM调优参数简介

1、 JVM参数简介

-XX 参数被称为不稳定参数,之所以这么叫是因为此类参数的设置很容易引起JVM 性能上的差异,使JVM 存在极大的不稳定性。如果此类参数设置合理将大大提高JVM 的性能及稳定性。

不稳定参数语法规则:

1.布尔类型参数值
-XX:+<option> ‘+’表示启用该选项
-XX:-<option> ‘-‘表示关闭该选项

2.数字类型参数值:
-XX:<option>=<number> 给选项设置一个数字类型值,可跟随单位,例如:’m’或’M’表示兆字节;’k’或’K’千字节;’g’或’G’千兆字节。32K与32768是相同大小的。

3.字符串类型参数值:
-XX:<option>=<string> 给选项设置一个字符串类型值,通常用于指定一个文件、路径或一系列命令列表。

例如:-XX:HeapDumpPath=./dump.core

 

2、 JVM参数示例

 

配置: -Xmx4g –Xms4g –Xmn1200m –Xss512k -XX:NewRatio=4 -XX:SurvivorRatio=8 -XX:PermSize=100m

-XX:MaxPermSize=256m -XX:MaxTenuringThreshold=15

解析:
-Xmx4g:堆内存最大值为4GB。

-Xms4g:初始化堆内存大小为4GB 。

-Xmn1200m:设置年轻代大小为1200MB。增大年轻代后,将会减小年老代大小。此值对系统性能影响较大,Sun官方推荐配置为整个堆的3/8。

-Xss512k:设置每个线程的堆栈大小。JDK5.0以后每个线程堆栈大小为1MB,以前每个线程堆栈大小为256K。应根据应用线程所需内存大小进行调整。在相同物理内存下,减小这个值能生成更多的线程。但是操作系统对一个进程内的线程数还是有限制的,不能无限生成,经验值在3000~5000左右。

-XX:NewRatio=4:设置年轻代(包括Eden和两个Survivor区)与年老代的比值(除去持久代)。设置为4,则年轻代与年老代所占比值为1:4,年轻代占整个堆栈的1/5

-XX:SurvivorRatio=8:设置年轻代中Eden区与Survivor区的大小比值。设置为8,则两个Survivor区与一个Eden区的比值为2:8,一个Survivor区占整个年轻代的1/10

-XX:PermSize=100m:初始化永久代大小为100MB。

-XX:MaxPermSize=256m:设置持久代大小为256MB。

-XX:MaxTenuringThreshold=15:设置垃圾最大年龄。如果设置为0的话,则年轻代对象不经过Survivor区,直接进入年老代。对于年老代比较多的应用,可以提高效率。如果将此值设置为一个较大值,则年轻代对象会在Survivor区进行多次复制,这样可以增加对象再年轻代的存活时间,增加在年轻代即被回收的概论。

 

三、 JVM调优目标

1. 何时需要做jvm调优?

什么情况下需要对jvm做调优?
1. heap 内存(老年代)持续上涨达到设置的最大内存值;
2. Full GC 次数频繁;
3. GC 停顿时间过长(超过1秒);
4. 应用出现OutOfMemory 等内存异常;
5. 应用中有使用本地缓存且占用大量内存空间;

6. 系统吞吐量与响应性能不高或下降。

 

2. JVM调优原则

JVM调优原则:
1、多数的Java应用不需要在服务器上进行JVM优化;

2、多数导致GC问题的Java应用,都不是因为我们参数设置错误,而是代码问题;

3、在应用上线之前,先考虑将机器的JVM参数设置到最优(最适合);

4、减少创建对象的数量;

5、减少使用全局变量和大对象;

6、JVM优化是到最后不得已才采用的手段;

7、在实际使用中,分析GC情况优化代码比优化JVM参数更好;

3. JVM调优目标

JVM调优目标 :
1. GC低停顿;

2. GC低频率;

3. 低内存占用;

4. 高吞吐量;

 

JVM调优量化目标(示例):
1. Heap 内存使用率 <= 70%;

2. Old generation内存使用率<= 70%;

3. avgpause <= 1秒;

4. Full gc 次数0 或 avg pause interval >= 24小时 ;

注意:不同应用,其JVM调优量化目标是不一样的。
四、 JVM调优经验

1. JVM调优经验总结

JVM调优的一般步骤为:
第1步:分析GC日志及dump文件,判断是否需要优化,确定瓶颈问题点;

第2步:确定JVM调优量化目标;

第3步:确定JVM调优参数(根据历史JVM参数来调整);

第4步:调优一台服务器,对比观察调优前后的差异;

第5步:不断的分析和调整,直到找到合适的JVM参数配置;

第6步:找到最合适的参数,将这些参数应用到所有服务器,并进行后续跟踪。

 

2. JVM调优重要参数解析

注意:不同应用,其JVM最佳稳定参数配置是不一样的。

配置: -server

-Xms12g -Xmx12g -XX:PermSize=500m -XX:MaxPermSize=1000m -Xmn2400m -XX:SurvivorRatio=1 -Xss512k  -XX:MaxDirectMemorySize=1G

-XX:+DisableExplicitGC -XX:CompileThreshold=8000 -XX:+UseConcMarkSweepGC  -XX:+UseParNewGC

-XX:+UseCompressedOops -XX:CMSInitiatingOccupancyFraction=60  -XX:ConcGCThreads=4

-XX:MaxTenuringThreshold=10  -XX:ParallelGCThreads=8

-XX:+ParallelRefProcEnabled  -XX:+CMSClassUnloadingEnabled  -XX:+CMSParallelRemarkEnabled

-XX:CMSMaxAbortablePrecleanTime=500 -XX:CMSFullGCsBeforeCompaction=4 -XX:+UseCMSInitiatingOccupancyOnly -XX:+UseCMSCompactAtFullCollection

-XX:+HeapDumpOnOutOfMemoryError  -verbose:gc  -XX:+PrintGCDetails  -XX:+PrintGCDateStamps  -Xloggc:/weblogic/gc/gc_$$.log

重要参数(可调优)解析:

-Xms12g:初始化堆内存大小为12GB。

-Xmx12g:堆内存最大值为12GB 。

-Xmn2400m:新生代大小为2400MB,包括 Eden区与2个Survivor区。

-XX:SurvivorRatio=1:Eden区与一个Survivor区比值为1:1。

-XX:MaxDirectMemorySize=1G:直接内存。报java.lang.OutOfMemoryError: Direct buffer memory 异常可以上调这个值。

-XX:+DisableExplicitGC:禁止运行期显式地调用 System.gc() 来触发fulll GC。

注意: Java RMI的定时GC触发机制可通过配置-Dsun.rmi.dgc.server.gcInterval=86400来控制触发的时间。

-XX:CMSInitiatingOccupancyFraction=60:老年代内存回收阈值,默认值为68。

-XX:ConcGCThreads=4:CMS垃圾回收器并行线程线,推荐值为CPU核心数。

-XX:ParallelGCThreads=8:新生代并行收集器的线程数。

-XX:MaxTenuringThreshold=10:设置垃圾最大年龄。如果设置为0的话,则年轻代对象不经过Survivor区,直接进入年老代。对于年老代比较多的应用,可以提高效率。如果将此值设置为一个较大值,则年轻代对象会在Survivor区进行多次复制,这样可以增加对象再年轻代的存活时间,增加在年轻代即被回收的概论。

-XX:CMSFullGCsBeforeCompaction=4:指定进行多少次fullGC之后,进行tenured区 内存空间压缩。

-XX:CMSMaxAbortablePrecleanTime=500:当abortable-preclean预清理阶段执行达到这个时间时就会结束。

3. 触发Full GC的场景及应对策略

年轻代空间(包括 Eden 和 Survivor 区域)回收内存被称为 Minor GC,对老年代GC称为MajorGC,而Full GC是对整个堆来说的,在最近几个版本的JDK里默认包括了对永生带即方法区的回收(JDK8中无永生带了),出现Full GC的时候经常伴随至少一次的Minor GC,但非绝对的。MajorGC的速度一般会比Minor GC慢10倍以上。

 

触发Full GC的场景及应对策略:

1.System.gc()方法的调用,应对策略:通过-XX:+DisableExplicitGC来禁止调用System.gc ;
2.老年代代空间不足,应对策略:让对象在Minor GC阶段被回收,让对象在新生代多存活一段时间,不要创建过大的对象及数组;
3.永生区空间不足,应对策略:增大PermGen空间
4.GC时出现promotionfailed和concurrent mode failure,应对策略:增大survivor space
5.Minor GC后晋升到旧生代的对象大小大于老年代的剩余空间,应对策略:增大Tenured space 或下调CMSInitiatingOccupancyFraction=60

6.   内存持续增涨达到上限导致Full GC  ,应对策略:通过dumpheap 分析是否存在内存泄漏

4. Gc日志分析工具

借助GCViewer日志分析工具,可以非常直观地分析出待调优点。

可从以下几方面来分析:

1. Memory, 分析 Totalheap 、 Tenuredheap 、 Youngheap 内存占用率及其他指标,理论上 内存占用率越小越好 ;
2. Pause  , 分析 Gc pause 、 Full gc pause 、 Total pause 三个大项中各指标,理论上 GC 次数越少越好, GC 时长越小越好 ;

5. MAT 堆内存分析工具

EclipseMemory Analysis Tools (MAT) 是一个分析Java堆数据的专业工具,用它可以定位内存泄漏的原因。

结束语

调优需谨慎,且调且珍惜

 


0 条评论

发表回复

Avatar placeholder

您的电子邮箱地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据