JVM参数解析与调优
Raymon
2017-06-28
Java
JVM 全称 Java Virtual Machine，Java程序编译之后生成的.class文件就是交由JVM执行，由JVM将.class文件内容翻译成对于系统可识别的机器语言，这就是Java之所以能一次编译，到处运行。
关于JVM配置以及调优是Java程序员进阶必须掌握的，一个优秀的Java程序员可以根据运行环境设置JVM参数，从而达到最优配置，合理充分的利用系统资源，避免生产环境发生一些如OOM的异常或者线程死锁、Java进程CPU消耗过高等问题。
JVM调试工具
jps (JVM Process Status Tool)
— 输出jvm运行的java进程状态信息
命令格式：
jps [options] [hostId]
hostId缺省值为当前主机 命令指令包括：
-q 不输出类名、Jar名和传入main方法的参数
-m 输出传入main方法的参数
-l 输出main类或Jar的全限名
-v 输出传入JVM的参数
使用如下：
[root@localhost ~]#
[root@localhost ~]# jps -m -l
28353 uyun.bat.monitor.impl.Startup
22852 uyun.bat.datastore.Startup
25799 uyun.bat.event.impl.Startup
19976 /opt/uyun/platform/jetty/start.jar
29320 uyun.bat.report.Startup
jstack
— 输出具体java进程内线程堆栈信息
jstask应该是比较常用的JVM调试工具，命令格式：
jstack [option] [pid]
命令指令：
-l long listings 打印线程锁信息，发生死锁时可以使用该参数调试
-m mixed mode 不仅输出java堆栈信息，还会输出C/C++堆栈信息
实际应用例子: 查看进程最占CPU的线程堆栈信息
- ps -ef | grep 查找对应进程，或者top命令查看系统使用信息，找出消耗最大的进程，我这里使用的是top命令:
top - 07:38:01 up 3 days, 6:20, 5 users, load average: 15.72, 15.02, 14.14
Tasks: 148 total, 7 running, 141 sleeping, 0 stopped, 0 zombie
%Cpu(s): 71.2 us, 26.1 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 2.7 si, 0.0 st
KiB Mem: 20397888 total, 20124388 used, 273500 free, 0 buffers
KiB Swap: 1081340 total, 1081340 used, 0 free. 2163376 cached Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
24152 es 20 0 3323892 492160 28496 S 35.7 2.4 1613:51 java
3247 mysql 20 0 1152924 297932 5836 S 9.9 1.5 418:51.47 mysqld
20009 root 20 0 3688420 1.563g 13132 S 7.9 8.0 653:51.83 java
22852 root 20 0 3450392 546480 12828 S 7.6 2.7 322:33.85 java
5779 root 20 0 3652656 1.114g 4976 S 4.3 5.7 109:57.89 java
28353 root 20 0 3624988 337680 12824 S 3.3 1.7 125:49.11 java
268 root 0 -20 0 0 0 S 2.3 0.0 43:33.35 kworker/0:1H
11539 root 20 0 369916 14108 4020 R 2.0 0.1 0:00.06 python
25799 root 20 0 3356336 475416 12832 S 1.7 2.3 64:56.00 java
1544 root 20 0 247448 27916 1144 S 1.3 0.1 56:24.67 redis-server
11540 root 20 0 131528 5048 3880 S 1.3 0.0 0:00.04 sshd
21497 root 20 0 3306144 313020 12712 S 1.0 1.5 20:59.73 java
1 root 20 0 133816 6772 2084 S 0.7 0.0 40:38.49 systemd
经过top命令查找，最占用CPU的是一个Java进程，进程id为24152，占用内存达到35.7%，经过ps -ef|grep pid查看，这个进程是ElasticSearch进程
- 第二步我们需要查找该进程内最耗费CPU的线程，可以使用ps -Lfp pid, ps -mp pid -o THREAD, top -Hp pid，这里我们用第三个命令，top -Hp 24152
top - 07:44:20 up 3 days, 6:27, 5 users, load average: 19.72, 15.50, 14.42
Threads: 40 total, 1 running, 39 sleeping, 0 stopped, 0 zombie
%Cpu(s): 64.3 us, 32.0 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 3.7 si, 0.0 st
KiB Mem: 20397888 total, 19894260 used, 503628 free, 0 buffers
KiB Swap: 1081340 total, 1081340 used, 0 free. 1994824 cached Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
24937 es 20 0 3319268 485312 21512 R 23.0 2.4 748:12.71 java
24953 es 20 0 3319268 485312 21512 S 4.3 2.4 151:27.67 java
24157 es 20 0 3319268 485312 21512 S 3.0 2.4 142:46.82 java
24459 es 20 0 3319268 485312 21512 S 0.3 2.4 1:58.92 java
24876 es 20 0 3319268 485312 21512 S 0.3 2.4 16:58.66 java
24152 es 20 0 3319268 485312 21512 S 0.0 2.4 0:00.00 java
24154 es 20 0 3319268 485312 21512 S 0.0 2.4 0:02.02 java
24155 es 20 0 3319268 485312 21512 S 0.0 2.4 0:00.00 java
24156 es 20 0 3319268 485312 21512 S 0.0 2.4 42:25.76 java
24158 es 20 0 3319268 485312 21512 S 0.0 2.4 0:31.47 java
这里我们看到最耗费性能的线程pid为24937
- 第三步先获取线程id 24937的十六进制值
[root@localhost ~]# printf "%x\n" 24937
6169
接着使用jstack来输出线程id 24937的堆栈信息，根据线程id的十六进制值grep
jstack 24152 | grep 6169
这里我遇到一个问题，执行jstack命令后系统并没有返回jvm信息，而是给出一个报错信息:
Unable to open socket file: target process not responding or HotSpot VM not loaded
之所以会报这个找不到文件的错误，首先我们得知道jvm运行时会生成一个hsperfdata_$user的目录，Linux下默认是在/tmp，我们也可以通过配置jvm启动参数-Djava.io.tmpdir来指定进程号信息临时文件的存放位置，检查过之后确认 /tmp下有生成目录hsperfdata_es
[root@localhost hsperfdata_es]# pwd
/tmp/hsperfdata_es
[root@localhost hsperfdata_es]# ls
24152
[root@localhost hsperfdata_es]#
那之所以jstack会报错找不到文件，原因是ElasticSearch进程是使用es用户启动的，而我们登录的是root账号，因此访问不到这个文件，切换用户为es后再次使用jstack打印线程堆栈信息:
[root@localhost hsperfdata_es]# su es
[es@localhost hsperfdata_es]$ jstack 24152 | grep 6169
"elasticsearch[Grenade][bulk][T#1]" #49 daemon prio=5 os_prio=0 tid=0x00007f78440b2000 nid=0x6169 runnable [0x00007f7840fa1000]
[es@localhost hsperfdata_es]$
打印出该线程信息，显示该线程是runnable正常运行的就绪状态，经查看详细堆栈信息，应该是es内部创建分片索引的进程，因此占用比较多性能，在对自己环境进程正式排查的时候，可以多进行几次打印，对比多次之间的线程运行情况，正常情况下由于程序运行速度是非常快的，如果发现多次打印对于线程都一直处于同一状态如Runnable，而且堆栈信息也卡在相同的几处地方，就可以考虑看一下对应代码是不是存在死循环或者方法调用缓慢的问题了。
jmap jhat
— jmap 输出堆内存使用情况 — jhat java堆内存分析工具
jmap和jhat经常在一起被使用。
jmap -hap pid
用于查看进程堆内存使用情况，包括堆配置参数和各代中堆内存使用情况，如：
whale.server01:/root# jmap -heap 17047
Attaching to process ID 17047, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 25.77-b03
using thread-local object allocation.
Parallel GC with 4 thread(s)
Heap Configuration:
MinHeapFreeRatio = 0
MaxHeapFreeRatio = 100
MaxHeapSize = 1073741824 (1024.0MB)
NewSize = 175112192 (167.0MB)
MaxNewSize = 357564416 (341.0MB)
OldSize = 351272960 (335.0MB)
NewRatio = 2
SurvivorRatio = 8
MetaspaceSize = 21807104 (20.796875MB)
CompressedClassSpaceSize = 1073741824 (1024.0MB)
MaxMetaspaceSize = 134217728 (128.0MB)
G1HeapRegionSize = 0 (0.0MB)
Heap Usage:
PS Young Generation
Eden Space:
capacity = 70254592 (67.0MB)
used = 22570248 (21.52466583251953MB)
free = 47684344 (45.47533416748047MB)
32.126366914208255% used
From Space:
capacity = 9961472 (9.5MB)
used = 6859688 (6.541908264160156MB)
free = 3101784 (2.9580917358398438MB)
68.86219225431743% used
To Space:
capacity = 10485760 (10.0MB)
used = 0 (0.0MB)
free = 10485760 (10.0MB)
0.0% used
PS Old Generation
capacity = 184025088 (175.5MB)
used = 99082056 (94.49201202392578MB)
free = 84943032 (81.00798797607422MB)
53.841602292835205% used
24334 interned Strings occupying 2508568 bytes.
使用jmap -histo[:live] pid查看堆内存中的对象数目、大小统计直方图，如果带上live则只统计活对象，如下：
whale.server01:/root# jmap -histo:live 17047 | more
num #instances #bytes class name
----------------------------------------------
1: 77521 8038136 [C
2: 1056 2890752 [J
3: 6362 2595656 [B
4: 5812 1968312 [I
5: 76614 1838736 java.lang.String
6: 19709 1734392 java.lang.reflect.Method
7: 18318 1268024 [Ljava.lang.Object;
8: 10179 1136280 java.lang.Class
9: 33025 1056800 java.util.concurrent.ConcurrentHashMap$Node
10: 12388 594624 org.aspectj.weaver.reflect.ShadowMatchImpl
11: 16901 540832 java.util.HashMap$Node
12: 12304 492160 java.util.LinkedHashMap$Entry
13: 12388 396416 org.aspectj.weaver.patterns.ExposedState
14: 2633 352464 [Ljava.util.HashMap$Node;
15: 11008 352256 java.util.Hashtable$Entry
16: 436 330440 [Ljava.util.concurrent.ConcurrentHashMap$Node;
17: 13383 321192 java.util.ArrayList
18: 9319 298208 java.lang.ref.WeakReference
19: 741 278616 java.lang.Thread
20: 17352 277632 java.lang.Object
21: 5707 228280 java.lang.ref.SoftReference
22: 3612 173376 java.util.HashMap
23: 302 164288 rx.internal.util.unsafe.SpscArrayQueue
24: 5104 163328 java.util.concurrent.locks.ReentrantLock$NonfairSync
25: 2872 160832 java.util.LinkedHashMap
26: 4784 153088 java.lang.ThreadLocal$ThreadLocalMap$Entry
27: 1828 146240 java.lang.reflect.Constructor
28: 1473 139856 [Ljava.lang.ThreadLocal$ThreadLocalMap$Entry;
29: 5152 123648 java.beans.MethodRef
30: 3831 119752 [Z
31: 5550 118632 [Ljava.lang.Class;
32: 2003 112168 java.security.Provider$Service
33: 464 107616 [Ljava.util.Hashtable$Entry;
附class对象说明：
B byte
C char
D double
F float
I int
J long
Z boolean
[ 数组，如[I表示int[]
[L+类名 其他对象
另一个场景是用jmap dump出进程内存使用情况，然后使用jhat分析。命令如下：
whale.server01:/root# jmap -dump:format=b,file=/tmp/dump.dat 17047
Dumping heap to /tmp/dump.dat ...
Heap dump file created
使用jhat查看：
jhat -port 9998 /tmp/dump.dat
执行完后在浏览器中打开 http://ip:9998 进行查看结果
jstat
— 输出jvm内存使用情况
jstat 监控系统整体资源使用情况，使用语法：
jstat -<option> [-t] [-h<lines>] <vmid> [<interval> [<count>]]
jstat 比较常用到场景是查看实时的垃圾回收统计，通常命令如下：
[root@localhost hsperfdata_root]# jstat -gc 19560 5000
即会每5秒一次显示进程为19560的GC情况：
S0C S1C S0U S1U EC EU OC OU MC MU CCSC CCSU YGC YGCT FGC FGCT GCT
17472.0 17472.0 275.9 0.0 139968.0 2271.9 349568.0 21151.3 55808.0 53992.8 6400.0 6044.1 5554 30.602 4 0.809 31.411
17472.0 17472.0 275.9 0.0 139968.0 58303.5 349568.0 21151.3 55808.0 53992.8 6400.0 6044.1 5554 30.602 4 0.809 31.411
17472.0 17472.0 275.9 0.0 139968.0 102692.6 349568.0 21151.3 55808.0 53992.8 6400.0 6044.1 5554 30.602 4 0.809 31.411
17472.0 17472.0 275.9 0.0 139968.0 103396.5 349568.0 21151.3 55808.0 53992.8 6400.0 6044.1 5554 30.602 4 0.809 31.411
17472.0 17472.0 275.9 0.0 139968.0 136708.8 349568.0 21151.3 55808.0 53992.8 6400.0 6044.1 5554 30.602 4 0.809 31.411
17472.0 17472.0 0.0 273.1 139968.0 31730.4 349568.0 21151.3 55808.0 53992.8 6400.0 6044.1 5555 30.605 4 0.809 31.414
17472.0 17472.0 0.0 273.1 139968.0 64034.4 349568.0 21151.3 55808.0 53992.8 6400.0 6044.1 5555 30.605 4 0.809 31.414
可以看出上例中第6次打印GC时，进行了一次YGC，对EU(eden usage)和S0U(Survivor0 usage)的内存空间进行了一次清理。
附上每列说明：
S0C：第一个幸存区的大小
S1C：第二个幸存区的大小
S0U：第一个幸存区的使用大小
S1U：第二个幸存区的使用大小
EC：伊甸园区的大小
EU：伊甸园区的使用大小
OC：老年代大小
OU：老年代使用大小
MC：方法区大小
MU：方法区使用大小
CCSC:压缩类空间大小
CCSU:压缩类空间使用大小
YGC：年轻代垃圾回收次数
YGCT：年轻代垃圾回收消耗时间
FGC：老年代垃圾回收次数
FGCT：老年代垃圾回收消耗时间
GCT：垃圾回收消耗总时间
JVM参数
JVM堆内存
整个堆大小 = 年轻代(Young Generation) + 年老代(Old Generation) + 持久代(Perm Area) JVM堆内存用与new创建的对象和数组，栈内存则用于分配基础类型变量和对象的引用，当程序运行到作用域外时，栈内引用将被释放，而失去了引用地址的堆内存里的对象则变为了垃圾，在未知时间被GC回收释放内存；
堆内存构成图： 
-Xms 初始堆大小 默认物理内存的1/64(小于1GB)空余堆大小小于40%时，JVM就会增大堆直到-Xmx的最大限制
-Xmx 最大堆大小 默认物理内存的1/4(小于1GB)空余堆大小大于70%时，JVM就会减少堆直到-Xms的最小限制
我们可以通过将“-Xms”和“-Xmx”设置为相同大小来获得一个固定大小的堆内存。 -Xms和-Xmx实际上是-XX:InitialHeapSize和-XX:MaxHeapSize的缩写。我们也可以直接使用这两个参数，它们所起得效果是一样的
-Xmn 年轻代大小
-XX:NewSize 设置年轻代初始大小
-XX:MaxNewSize 年轻代最大值
-XX:PermSize 设置持久代初始值
-XX:MaxPermSize 设置持久代最大值
-Xss 每个线程堆栈大小 JDK5.0以后每个线程堆栈大小为1M，以前每个线程堆栈大小为256K，这个参数对影响比较大，需经过严格测试后进行调整
-XX:NewRatio 年轻代(包括Eden和两个Survivor区)与年老代的比值(除去持久代) -XX:NewRatio=4表示年轻代与年老代所占比值为1:4,年轻代占整个堆栈的1/5，Xms=Xmx并且设置了Xmn的情况下，该参数不需要进行设置。
-XX:SurvivorRatio Eden区与Survivor区的大小比值 设置为8,则两个Survivor区与一个Eden区的比值为2:8,一个Survivor区占整个年轻代的1/10
-XX:+HeapDumpOnOutOfMemoryError and -XX:HeapDumpPath 当我们没法为-Xmx（最大堆内存）设置一个合适的大小，那么就有可能面临内存溢出（OutOfMemoryError）的风险，这可能是我们使用JVM时面临的最可怕的猛兽之一导致内存溢出的根本原因需要仔细的定位。通常来说，分析堆内存快照（Heap Dump）是一个很好的定位手段，如果发生内存溢出时没有生成内存快照，特别是对于那种JVM已经崩溃或者错误只出现在顺利运行了数小时甚至数天的生产系统上时，将很难去分析崩溃问题。
幸运的是，我们可以通过设置 -XX:+HeapDumpOnOutOfMemoryError 让JVM在发生内存溢出时自动的生成堆内存快照。有了这个参数，当我们不得不面对内存溢出异常的时候会节约大量的时间。默认情况下，堆内存快照会保存在JVM的启动目录下名为java_pid.hprof 的文件里（在这里就是JVM进程的进程号）。也可以通过设置-XX:HeapDumpPath=来改变默认的堆内存快照生成路径， 可以是相对或者绝对路径。
Gitalk 加载中 …
