JVM-调优工具详解及调优实战
调优工具
jps
- 查看正在运行java的进程
jmap
jmap -histo 30340 #查看历史生成的实例
jmap -histo:live 30340 #查看当前存活的实例,执行过程中可能会触发一次full gc
- num:序号
- instances:实例数量
- bytes:占用空间大小
- class name:类名称,[C is a char[],[S is a short[],[I is a int[],[B is a byte[],[[I is a int[][]
jmap -dump:format=b,file=/Users/mac/Desktop/java学习/Dump/2.hprof 31274
- 将创建出来的dump文件放入/Users/mac/Desktop/java学习/Dump文件夹中。
- 生成的dump文件可以通过perfma解析dump文件查看一些内存信息。
jstack
- 使用jstack 查看线程死锁问题
jstack -pid
“Thread-1” 线程名
prio=5 优先级=5
tid=0x000000001fa9e000 线程id
nid=0x2d64 线程对应的本地线程标识nid
java.lang.Thread.State: BLOCKED 线程状态
- 可以看得出来是Thread-1 在等Thread-0的锁,Thread-0 在等Thread-1的锁,所以死锁。
查看cpu使用最频繁的代码
- 使用top命令 找出使用最频繁的线程
- 使用jstack 通过线程id 找到对应代码
jinfo
- 查看jvm的参数
jinfo -flags <pid># 查找出所有的参数
jstat
jstat -gc pid 1000 10# 评估gc 压力 每1秒输出,一共输出10次
- S0C:第一个幸存区的大小,单位KB
- S1C:第二个幸存区的大小
- S0U:第一个幸存区的使用大小
- S1U:第二个幸存区的使用大小
- EC:伊甸园区的大小
- EU:伊甸园区的使用大小
- OC:老年代大小
- OU:老年代使用大小
- MC:方法区大小(元空间)
- MU:方法区使用大小
- CCSC:压缩类空间大小
- CCSU:压缩类空间使用大小
- YGC:年轻代垃圾回收次数
- YGCT:年轻代垃圾回收消耗时间,单位s
- FGC:老年代垃圾回收次数
- FGCT:老年代垃圾回收消耗时间,单位s
- GCT:垃圾回收消耗总时间,单位s
也可以使用 参数**-Xloggc:/Users/mac/Desktop/java学习/GC/gc-%t.log**
- 将文件输入到 /Users/mac/Desktop/java学习/GC/gc-%t.log中然后使用工具gceasy来分析gc文件
JVM运行情况预估
年轻代对象增长的速率
- 可以执行命令 jstat -gc pid 1000 10 (每隔1秒执行1次命令,共执行10次),通过观察EU(eden区的使用)来估算每秒eden大概新增多少对象,如果系统负载不高,可以把频率1秒换成1分钟,甚至10分钟来观察整体情况。注意,一般系统可能有高峰期和日常期,所以需要在不同的时间分别估算不同情况下对象增长速率。
Young GC的触发频率和每次耗时
- 知道年轻代对象增长速率我们就能推根据eden区的大小推算出Young GC大概多久触发一次,Young GC的平均耗时可以通过 YGCT/YGC 公式算出,根据结果我们大概就能知道系统大概多久会因为Young GC的执行而卡顿多久。
每次Young GC后有多少对象存活和进入老年代
- 这个因为之前已经大概知道Young GC的频率,假设是每5分钟一次,那么可以执行命令 jstat -gc pid 300000 10 ,观察每次结果eden,survivor和老年代使用的变化情况,在每次gc后eden区使用一般会大幅减少,survivor和老年代都有可能增长,这些增长的对象就是每次Young GC后存活的对象,同时还可以看出每次Young GC后进去老年代大概多少对象,从而可以推算出老年代对象增长速率。
Full GC的触发频率和每次耗时
- 知道了老年代对象的增长速率就可以推算出Full GC的触发频率了,Full GC的每次耗时可以用公式 FGCT/FGC 计算得出。
优化思路其实简单来说就是尽量让每次Young GC后的存活对象小于Survivor区域的50%,都留存在年轻代里。尽量别让对象进入老年代。尽量减少Full GC的频率,避免频繁Full GC对JVM性能的影响。
Arthas使用文档
- 进入下载Arthas的文件夹 运行 ./as.sh
- 命令:dashboard
输入dashboard可以查看整个进程的运行情况,线程、内存、GC、运行环境信息: - thread 进程ID 查看详细情况
- thread -b 查看死锁
实战:解决Full GC卡顿的思路
- 是否元空间导致的Full GC
- 是否 大量“朝生夕死”的对象 到了老年代
- 一次young GC到survivor区的对象,由于太多会导致很多survivor区的对象直接进入老年代
- 空间担保机制导致2次Full GC
- 由于老年代的内存小于平均晋升大小,一次fullGC 再young GC
- young GC后晋升到老年代 再次Full GC
- 是否大对象到了老年代