“解剖“JVM之GC调优
目录
前言
一、JDK工具类
1.Jmap
2.Jstack
3.Jinfo
4.Jstat
二、JVM运行情况预估
总结
前言
前面所说的JVM垃圾收集其实最终也是为了解决GC的，那么GC又是如何调优的呢？
其实说白了调优就是为了使程序运行的更好，更快，减少卡顿。这个过程就会使用许多工具来查找到问题发生的原因，解决这些问题来达到我们的目的。
接下来我们就用程序的实例来说明如何进行调优的。
先随便启动一个应用程序，我们可以使用 jps 查看改应用的进程id。
如何使用工具类请看：JVM调优 | ProcessOn免费在线作图,在线流程图,在线思维导图
一、JDK工具类
1.Jmap
用该命令来查看内存信息，实例个数以及占用内存大小。
jmap -histo 18984 > ./log.txt打开对应的log.txt文件可以看到文件内容如下：
顶部每个字段的含义如下：
- 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 -heap 18984
堆内存dump：
jmap -dump:format=b,file=test.hprof 18984
也可以设置内存溢出自动导出dump文件(内存很大的时候，可能会导不出来)
- -XX:+HeapDumpOnOutOfMemoryError
- -XX:HeapDumpPath=./ （路径）
示例代码如下：
public class OOMTest {
public static List执行完毕后就可以在D盘中看到 jvm.dump 的文件，然后我们把该文件导入到 jvisualvm 中进行 dump 文件的分析。
2.Jstack
可以用 jstack 加进程 id 查找死锁。示例如下：
public class DeadLockTest {
private static Object lock1 = new Object();
private static Object lock2 = new Object();
public static void main(String[] args) {
new Thread(() -> {
synchronized (lock1) {
try {
System.out.println("thread1 begin");
Thread.sleep(5000);
} catch (InterruptedException e) {
}
synchronized (lock2) {
System.out.println("thread1 end");
}
}
}).start();
new Thread(() -> {
synchronized (lock2) {
try {
System.out.println("thread2 begin");
Thread.sleep(5000);
} catch (InterruptedException e) {
}
synchronized (lock1) {
System.out.println("thread2 end");
}
}
}).start();
System.out.println("main thread end");
}
}执行该程序后，执行 jstack pid 就可以看到
当然还可以用 jvisualvm 自动检测死锁：
用 jstack 找出占用 CPU 最高的线程堆栈信息，示例代码如下：
public class CPURiseTest {
public static final int initData = 666;
public static User user = new User();
public int compute() { //一个方法对应一块栈帧内存区域
int a = 1;
int b = 2;
int c = (a + b) * 10;
return c;
}
public static void main(String[] args) {
CPURiseTest riseTest = new CPURiseTest();
while (true){
riseTest.compute();
}
}
}把该应用程序编译后到 Linux 环境下面运行：
1，使用命令top -p ，显示你的java进程的内存情况，pid是你的java进程号，比如19663。
2，按H，获取每个线程的内存情况。
3，找到内存和cpu占用最高的线程tid，比如19664
4，转为十六进制得到 0x4cd0，此为线程id的十六进制表示
5，执行 jstack 19663|grep -A 10 4cd0，得到线程堆栈信息中 4cd0 这个线程所在行的后面10行，从堆栈中可以发现导致cpu飙高的调用方法。
6，查看对应的堆栈信息找出可能存在问题的代码。
3.Jinfo
可以使用 Jinfo 命令查看正在运行的 Java 应用程序的扩展参数：
jinfo -flags 
查看 Java 系统参数：
jinfo -sysprops 
4.Jstat
jstat命令可以查看堆内存各部分的使用量，以及加载类的数量。命令的格式如下：
jstat -垃圾回收统计（最常用）：可以评估程序内存使用及GC压力整体情况
jstat -gc 
| 参数 | 含义 |
|---|---|
| S0C | 第一个幸存区的大小，单位KB |
| S1C | 第二个幸存区的大小 |
| S0U | 第一个幸存区的使用大小 |
| S1U | 第二个幸存区的使用大小 |
| EC | 伊甸园区的大小 |
| EU | 伊甸园区的使用大小 |
| OC | 老年代大小 |
| OU | 老年代使用大小 |
| MC | 方法区大小(元空间) |
| MU | 方法区使用大小 |
| CCSC | 压缩类空间大小 |
| CCSU | 压缩类空间使用大小 |
| YGC | 年轻代垃圾回收次数 |
| YGCT | 年轻代垃圾回收消耗时间，单位s |
| FGC | 老年代垃圾回收次数 |
| FGCT | 老年代垃圾回收消耗时间，单位s |
| GCT | 垃圾回收消耗总时间，单位s |
堆内存统计：
jstat -gccapacity 
新生代垃圾回收统计：
jstat -gcnew 
| 参数 | 含义 |
|---|---|
| S0C | 第一个幸存区的大小 |
| S1C | 第二个幸存区的大小 |
| S0U | 第一个幸存区的使用大小 |
| S1U | 第二个幸存区的使用大小 |
| TT | 对象在新生代存活的次数 |
| MTT | 对象在新生代存活的最大次数 |
| DSS | 期望的幸存区大小 |
| EC | 伊甸园区的大小 |
| EU | 伊甸园区的使用大小 |
| YGC | 年轻代垃圾回收次数 |
| YGCT | 年轻代垃圾回收消耗时间 |
新生代内存统计：
jstat -gcnewcapacity 
| 参数 | 含义 |
|---|---|
| NGCMN | 新生代最小容量 |
| NGCMX | 新生代最大容量 |
| NGC | 当前新生代容量 |
| S0CMX | 最大幸存1区大小 |
| S0C | 当前幸存1区大小 |
| S1CMX | 最大幸存2区大小 |
| S1C | 当前幸存2区大小 |
| ECMX | 最大伊甸园区大小 |
| EC | 当前伊甸园区大小 |
| YGC | 年轻代垃圾回收次数 |
| FGC | 老年代回收次数 |
老年代垃圾回收统计：
jstat -gcold 
| 参数 | 含义 |
|---|---|
| MC | 方法区大小 |
| MU | 方法区使用大小 |
| CCSC | 压缩类空间大小 |
| CCSU | 压缩类空间使用大小 |
| OC | 老年代大小 |
| OU | 老年代使用大小 |
| YGC | 年轻代垃圾回收次数 |
| FGC | 老年代垃圾回收次数 |
| FGCT | 老年代垃圾回收消耗时间 |
| GCT | 垃圾回收消耗总时间 |
老年代内存统计
jstat -gcoldcapacity 
| 参数 | 含义 |
|---|---|
| OGCMN | 老年代最小容量 |
| OGCMX | 老年代最大容量 |
| OGC | 当前老年代大小 |
| OC | 老年代大小 |
| YGC | 年轻代垃圾回收次数 |
| FGC | 老年代垃圾回收次数 |
| FGCT | 老年代垃圾回收消耗时间 |
| GCT | 垃圾回收消耗总时间 |
元空间数据统计
jstat -gcmetacapacity 
| 参数 | 含义 |
|---|---|
| MCMN | 最小元数据容量 |
| MCMX | 最大元数据容量 |
| MC | 当前元数据空间大小 |
| CCSMN | 最小压缩类空间大小 |
| CCSMX | 最大压缩类空间大小 |
| CCSC | 当前压缩类空间大小 |
| YGC | 年轻代垃圾回收次数 |
| FGC | 老年代垃圾回收次数 |
| FGCT | 老年代垃圾回收消耗时间 |
| GCT | 垃圾回收消耗总时间 |
二、JVM运行情况预估
用 jstat gc -pid 命令可以计算出如下一些关键数据，有了这些数据就可以采用之前介绍过的优化思路，先给自己的系统设置一些初始性的JVM参数，比如堆内存大小，年轻代大小，Eden和Survivor的比例，老年代的大小，大对象的阈值，大龄对象进入老年代的阈值等。
年轻代对象增长的速率
可以执行命令 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性能的影响。
总结
其实调优就是为了加速程序的进行，减少卡顿。具体的调优就是用调优工具分析到相应的代码或者参数配置等问题去具体的修改。