JVM内存分析排查工具
- 1.JDK自带的性能调优工具
- 2.Arthas线上分析工具的使用
- 1、处理内存溢出，报OutOfMemoryError错误第一步：通过jmap -histo命令查看系统内存使用情况
- 第二步：分析内存溢出，查看堆空间占用情况
- 第三步：导出dump内存溢出的文件，导入到jvisualvm查看
- 2、CPU使用猛增，这个问题如何排查？
- 第一步：运行代码，使用top命令查看cpu占用情况
- 第二步：使用top -p 命令查看飙高进程
- 第三步：按H，获取每个线程的内存情况
- 第四步：找到内存和cpu占用最高的线程tid
- 第五步：将线程tid转化为十六进制
- 第六步：执行[ jstack 4018360|grep -A 10 67187778] 查询飙高线程的堆栈信息
- 第七步：查看对应的堆栈信息找出可能存在问题的代码
- 3、进程有死锁，这个问题如何排查？
- 第二步：使用jvisualvm查看死锁
- 4、JVM参数调优
- 1. 垃圾回收统计 jstat -gc
- 2.堆内存统计
- 3.新生代垃圾回收统计
- 4. 新生代内存统计
- 5. 老年代垃圾回收统计
- 6. 老年代内存统计
- 7. 元数据空间统计
- 8.整体运行情况
虚拟机性能监控、故障处理工具
Java开发人员肯定都知道JDK的bin目录中有java.exe、javac.exe这两个命令行工具，但并非所有程序员都了解过JDK的bin目录下其他各种小工具的作用。随着JDK版本的更迭，这些小工具的数量和功能也在不知不觉地增加与增强。除了编译和运行Java程序外，打包、部署、签名、调试、监控、运维等各种场景都可能会用到它们。
Arthas线上分析诊断调优工具
以前我们要排查线上问题，通常使用的是jdk自带的调优工具和命令。最常见的就是dump线上日志，然后下载到本地，导入到jvisualvm工具中。这样操作有诸多不变，现在阿里团队开发的Arhtas工具，拥有非常强大的功能，并且都是线上的刚需，尤其是情况紧急，不方便立刻发版，适合临时处理危急情况使用。下面分两部分来研究JVM性能调优工具：
1.JDK自带的性能调优工具
虽然有了Arthas，但也不要忘记JDK自带的性能调优工具，在某些场景下，他还是有很大作用的。而且Arthas里面很多功能其根本就是封装了JDK自带的这些调优命令。
2.Arthas线上分析工具的使用
这一部分，主要介绍几个排查线上问题常用的方法。功能真的很强大，刚兴趣的猿媛可以研究其基本原理。之前跟我同事讨论，感觉这就像病毒一样，可以修改内存里的东西，真的还是挺强大的。
以上两种方式排查线上问题，没有优劣之分，如果线上不能安装Arthas就是jdk自带命令，如果jdk自带命令不能满足部分要求，又可以安装Arthas，那就使用Arthas。他们只是排查问题的工具，重要的是排查问题的思路。不管黑猫、白猫，能抓住耗子就是好猫。
一、JDK自带的调优工具
这里不是流水一样的介绍功能怎么用，就说说线上遇到的问题，我们通常怎么排查，排查的几种情况。
内存溢出，出现OutOfMemoryError，这个问题如何排查 CPU使用猛增，这个问题如何排查？进程有死锁，这个问题如何排查？JVM参数调优
下面来一个一个解决
1、处理内存溢出，报OutOfMemoryError错误第一步：通过jmap -histo命令查看系统内存使用情况
使用的命令：
jmap -histo 进程号
运行结果：
num #instances #bytes class name
----------------------------------------------
1: 1101980 372161752 [B
2: 551394 186807240 [Ljava.lang.Object;
3: 1235341 181685128 [C
4: 76692 170306096 [I
5: 459168 14693376 java.util.concurrent.locks.AbstractQueuedSynchronizer$Node
6: 543699 13048776 java.lang.String
7: 497636 11943264 java.util.ArrayList
8: 124271 10935848 java.lang.reflect.Method
9: 348582 7057632 [Ljava.lang.Class;
10: 186244 5959808 java.util.concurrent.ConcurrentHashMap$Node
8671: 1 16 zipkin2.reporter.Reporter$1
8672: 1 16 zipkin2.reporter.Reporter$2
Total 8601492 923719424
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 -histro 进程号】运行出来的结果，直接去了其中的一部分。通过这里我们可以看看大的实例对象中，有没有我们自定义的实例对象。通过这个可以排查出哪个实例对象引起的内存溢出。
除此之外，Total汇总数据可以看出当前一共有多少个对象，暂用了多大内存空间。这里是有约24w个对象，占用约28388336字节对象，换算下来27M的空间。
第二步：分析内存溢出，查看堆空间占用情况
使用命令
jhsdb jmap --heap --pid 进程号
运行结果
[root@iZ2pl8Z ~]# jhsdb jmap --heap --pid 28692
Attaching to process ID 28692, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 11.0.13+10-LTS-370
using thread-local object allocation.
Garbage-First (G1) GC with 4 thread(s)
Heap Configuration:
MinHeapFreeRatio = 40
MaxHeapFreeRatio = 70
MaxHeapSize = 2065694720 (1970.0MB)
NewSize = 1363144 (1.2999954223632812MB)
MaxNewSize = 1239416832 (1182.0MB)
OldSize = 5452592 (5.1999969482421875MB)
NewRatio = 2
SurvivorRatio = 8
MetaspaceSize = 21807104 (20.796875MB)
CompressedClassSpaceSize = 1073741824 (1024.0MB)
MaxMetaspaceSize = 17592186044415 MB
G1HeapRegionSize = 1048576 (1.0MB)
Heap Usage:
G1 Heap:
regions = 1970
capacity = 2065694720 (1970.0MB)
used = 467303384 (445.65523529052734MB)
free = 1598391336 (1524.3447647094727MB)
22.622093161955704% used
G1 Young Generation:
Eden Space:
regions = 263
capacity = 464519168 (443.0MB)
used = 275775488 (263.0MB)
free = 188743680 (180.0MB)
59.36794582392776% used
Survivor Space:
regions = 6
capacity = 6291456 (6.0MB)
used = 6291456 (6.0MB)
free = 0 (0.0MB)
100.0% used
G1 Old Generation:
regions = 179
capacity = 275775488 (263.0MB)
used = 186285016 (177.65523529052734MB)
free = 89490472 (85.34476470947266MB)
67.54951912187352% used
下面来看看参数的含义
堆空间配置信息：
Heap Configuration:
/**
- 空闲堆空间的最小百分比，计算公式为：HeapFreeRatio =(CurrentFreeHeapSize/CurrentTotalHeapSize) * 100，值的区间为0 * 到100，默认值为 40。如果HeapFreeRatio < MinHeapFreeRatio，则需要进行堆扩容，扩容的时机应该在每次垃圾回收之后。
*/
MinHeapFreeRatio = 40
/**
- 空闲堆空间的最大百分比，计算公式为：HeapFreeRatio =(CurrentFreeHeapSize/CurrentTotalHeapSize) * 100，值的区间为0
- 到100，默认值为 70。如果HeapFreeRatio > MaxHeapFreeRatio，则需要进行堆缩容，缩容的时机应该在每次垃圾回收之后
*/
MaxHeapFreeRatio = 70
/**JVM 堆空间允许的最大值*/
MaxHeapSize = 2065694720 (1970.0MB)
/** JVM 新生代堆空间的默认值*/
NewSize = 1363144 (1.2999954223632812MB)
/** JVM 新生代堆空间允许的最大值 */
MaxNewSize = 1239416832 (1182.0MB)
/** JVM 老年代堆空间的默认值 */
OldSize = 5452592 (5.1999969482421875MB)
/** 新生代（2个Survivor区和Eden区 ）与老年代（不包括永久区）的堆空间比值，表示新生代：老年代=1：2*/
NewRatio = 2
/** 两个Survivor区和Eden区的堆空间比值为 8，表示 S0 ：S1 ：Eden = 1：1：8 */
SurvivorRatio = 8
/** JVM 元空间的默认值 */
MetaspaceSize = 21807104 (20.796875MB)
CompressedClassSpaceSize = 1073741824 (1024.0MB)
/** JVM 元空间允许的最大值 */
MaxMetaspaceSize = 17592186044415 MB
/** 在使用 G1 垃圾回收算法时，JVM 会将 Heap 空间分隔为若干个 Region，该参数用来指定每个 Region 空间的大小 */
G1HeapRegionSize = 1048576 (1.0MB)
G1堆使用情况
Heap Usage:
G1 Heap:
regions = 1970
capacity = 2065694720 (1970.0MB)
used = 467303384 (445.65523529052734MB)
free = 1598391336 (1524.3447647094727MB)
22.622093161955704% used
G1 的 Heap 使用情况，该 Heap 包含 1970 个 Region，结合上文每个 RegionSize=1M，因此 Capacity = Regions * RegionSize = 1970 * 1M = 1970M，已使用空间为 445.65M，空闲空间为 1524.34M，使用率为 22.62%。
G1年轻代Eden区使用情况
G1 Young Generation:
Eden Space:
regions = 263
capacity = 464519168 (443.0MB)
used = 275775488 (263.0MB)
free = 188743680 (180.0MB)
59.36794582392776% used
G1 的 Eden 区的使用情况，总共使用了 263 个 Region，结合上文每个 RegionSize=1M，因此 Used = Regions * RegionSize = 263 * 1M = 263M，Capacity=443M 表明当前 Eden 空间分配了 443 个 Region，使用率为 59.37%。
G1年轻代Survivor区使用情况和G1老年代使用情况：和Eden区类似
Survivor Space:
regions = 6
capacity = 6291456 (6.0MB)
used = 6291456 (6.0MB)
free = 0 (0.0MB)
100.0% used
G1 Old Generation:
regions = 179
capacity = 275775488 (263.0MB)
used = 186285016 (177.65523529052734MB)
free = 89490472 (85.34476470947266MB)
67.54951912187352% used
Survivor区使用情况和Eden区类似。老年代参数含义和Eden区类似。通过上面的命令，我们就能知道当前系统对空间的使用情况了，到底是老年代有问题还是新生代有问题。
第三步：导出dump内存溢出的文件，导入到jvisualvm查看
如果前两种方式还是没有排查出问题，我们可以导出内存溢出的日志，在导入客户端进行分析
使用的命令是：
jmap -dump:file=a.dump 进程号
或者是直接设置JVM参数
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=./ （路径） 然后导入到jvisualvm中进行分析，方法是：点击文件->装入，导入文件，查看系统的运行情况了。
b9a81c9dd83003845a3d32f37c7f078f
通过分析实例数，看看哪个对象实例占比最高，这里重点看我们自定义的类，然后分析这个对象里面有没有大对象，从而找出引起内存溢出的根本原因。
2、CPU使用猛增，这个问题如何排查？
我们可以通过Jstack找出占用cpu最高的线程的堆栈信息，下面来一步一步分析。
假设我们有一段死循环，不断执行方法调用，线程始终运行不释放就会导致CPU飙高，示例代码如下：
public class Math {
public static int initData = 666;
public static User user = new User();
public User user1;
public int compute() {
int a = 1;
int b = 2;
int c = (a + b) * 10;
return c;
}
public static void main(String[] args) {
Math math = new Math();
while(true){
math.compute();
}
}
}
第一步：运行代码，使用top命令查看cpu占用情况
如上，现在有一个java进程，cpu严重飙高了，接下来如何处理呢？
第二步：使用top -p 命令查看飙高进程
top -p 46518
我们看到了单独的46518这个线程的详细信息
第三步：按H，获取每个线程的内存情况
需要注意的是，这里的H是大写的H。
我们可以看出线程0和线程1线程号飙高。
第四步：找到内存和cpu占用最高的线程tid
通过上图我们看到占用cpu资源最高的线程有两个，线程号分别是4018362，4018363。我们一第一个为例说明，如何查询这个线程是哪个线程，以及这个线程的什么地方出现问题，导致cpu飙高。
第五步：将线程tid转化为十六进制
67187778是线程号为4013442的十六进制数。具体转换可以网上查询工具。
第六步：执行[ jstack 4018360|grep -A 10 67187778] 查询飙高线程的堆栈信息
接下来查询飙高线程的堆栈信息
jstack 4013440|grep -A 10 67190882
4013440：表示的是进程号 67187778：表示的是线程号对应的十六进制数 通过这个方式可以查询到这个线程对应的堆栈信息
从这里我们可以看出有问题的线程id是0x4cd0, 哪一句代码有问题呢，Math类的22行。
第七步：查看对应的堆栈信息找出可能存在问题的代码
上述方法定位问题已经很精确了，接下来就是区代码里排查为什么会有问题了。
备注：上面的进程id可能没有对应上，在测试的时候，需要写对进程id和线程id
3、进程有死锁，这个问题如何排查？
Jstack可以用来查看堆栈使用情况，以及进程死锁情况。下面就来看看如何排查进程死锁
还是通过案例来分析
package com.lxl.jvm;
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();
}
}
上面是两把锁，互相调用。
定义了两个成员变量lock1，lock2 main方法中定义了两个线程。线程1内部使用的是同步执行--上锁，锁是lock1。休眠5秒钟之后，他要获取第二把锁，执行第二段代码。线程2和线程1类似，锁相反。问题：一开始，像个线程并行执行，线程一获取lock1，线程2获取lock2.然后线程1继续执行，当休眠5s后获取开启第二个同步执行，锁是lock2，但这时候很可能线程2还没有执行完，所以还没有释放lock2，于是等待。线程2刚开始获取了lock2锁，休眠五秒后要去获取lock1锁，这时lock1锁还没释放，于是等待。两个线程就处于相互等待中，造成死锁。第一步：通过Jstack命令来看看是否能检测到当前有死锁。
jstack 51789
从这里面个异常可以看出，
prio：当前线程的优先级 cpu：cpu耗时 os_prio：操作系统级别的优先级 tid：线程id nid：系统内核的id state：当前的状态，BLOCKED，表示阻塞。通常正常的状态是Running我们看到Thread-0和Thread-1线程的状态都是BLOCKED. 通过上面的信息，我们判断出两个线程的状态都是BLOCKED，可能有点问题，然后继续往下看。
我们从最后的一段可以看到这句话：Found one Java-level deadlock; 意思是找到一个死锁。死锁的线程号是Thread-0，Thread-1。
Thread-0：正在等待0x000000070e706ef8对象的锁，这个对象现在被Thread-1持有。
Thread-1：正在等待0x000000070e705c98对象的锁，这个对象现在正在被Thread-0持有。
最下面展示的是死锁的堆栈信息。死锁可能发生在DeadLockTest的第17行和第31行。通过这个提示，我们就可以找出死锁在哪里了。
第二步：使用jvisualvm查看死锁
如果使用jstack感觉不太方便，还可以使用jvisualvm，通过界面来查看，更加直观。
在程序代码启动的过程中，打开jvisualvm工具。
找到当前运行的类，查看线程，就会看到最头上的一排红字：检测到死锁。然后点击“线程Dump”按钮，查看相信的线程死锁的信息。
这里可以找到线程私锁的详细信息，具体内容和上面使用Jstack命令查询的结果一样，这里实用工具更加方便。
4、JVM参数调优
jvm调优通常使用的是Jstat命令。一般每隔一段时间响应变慢就是gc导致的，通过前文gc算法得知清理空间的标记清除算法需要一定时间复制对象。
1. 垃圾回收统计 jstat -gc
jstat -gc 进程id
这个命令非常常用，在线上有问题的时候，可以通过这个命令来分析问题。
下面我们来测试一下，启动一个项目，然后在终端驶入jstat -gc 进程id，得到如下结果：
上面的参数分别是什么意思呢？先识别参数的含义，然后根据参数进行分析
- S0C: 第一个Survivor区的容量
- S1C: 第二个Survivor区的容量
- S0U: 第一个Survivor区已经使用的容量
- S1U:第二个Survivor区已经使用的容量
- EC: 新生代Eden区的容量
- EU: 新生代Eden区已经使用的容量
- OC: 老年代容量
- OU:老年代已经使用的容量
- MC: 方法区大小（元空间）
- MU: 方法区已经使用的大小
- CCSC:压缩指针占用空间
- CCSU:压缩指针已经使用的空间
- YGC: YoungGC已经发生的次数
- YGCT: 这一次YoungGC耗时
- FGC: Full GC发生的次数
- FGCT: Full GC耗时
- GCT: 总的GC耗时，等于YGCT+FGCT 连续观察GC变化的命令
jstat -gc 进程ID 间隔时间 打印次数
举个例子：我要打印10次gc信息，每次间隔1秒
jstat -gc 进程ID 1000 10
这样就连续打印了10次gc的变化，每次隔一秒。
这个命令是对整体垃圾回收情况的统计，下面将会差分处理。
2.堆内存统计
这个命令是打印堆内存的使用情况。
jstat -gccapacity 进程ID
11111
- NGCMN：新生代最小容量
- NGCMX：新生代最大容量
- NGC：当前新生代容量
- S0C：第一个Survivor区大小
- S1C：第二个Survivor区大小
- EC：Eden区的大小
- OGCMN：老年代最小容量
- OGCMX：老年代最大容量
- OGC：当前老年代大小
- OC: 当前老年代大小
- MCMN: 最小元数据容量
- MCMX：最大元数据容量
- MC：当前元数据空间大小
- CCSMN：最小压缩类空间大小
- CCSMX：最大压缩类空间大小
- CCSC：当前压缩类空间大小
- YGC：年轻代gc次数
- FGC：老年代GC次数
3.新生代垃圾回收统计
命令：
jstat -gcnew 进程ID [ 间隔时间 打印次数]
这个指的是当前某一次GC的内存情况
- S0C：第一个Survivor的大小
- S1C：第二个Survivor的大小
- S0U：第一个Survivor已使用大小
- S1U：第二个Survivor已使用大小
- TT: 对象在新生代存活的次数
- MTT: 对象在新生代存活的最大次数
- DSS: 期望的Survivor大小
- EC：Eden区的大小
- EU：Eden区的使用大小
- YGC：年轻代垃圾回收次数
- YGCT：年轻代垃圾回收消耗时间
4. 新生代内存统计
jstat -gcnewcapacity 进程ID
参数含义：
- NGCMN：新生代最小容量
- NGCMX：新生代最大容量
- NGC：当前新生代容量
- S0CMX：Survivor 1区最大大小
- S0C：当前Survivor 1区大小
- S1CMX：Survivor 2区最大大小
- S1C：当前Survivor 2区大小
- ECMX：最大Eden区大小
- EC：当前Eden区大小
- YGC：年轻代垃圾回收次数
- FGC：老年代回收次数
5. 老年代垃圾回收统计
命令：
jstat -gcold 进程ID
参数含义：
- MC：方法区大小
- MU：方法区已使用大小
- CCSC:压缩指针类空间大小
- CCSU:压缩类空间已使用大小
- OC：老年代大小
- OU：老年代已使用大小
- YGC：年轻代垃圾回收次数
- FGC：老年代垃圾回收次数
- FGCT：老年代垃圾回收消耗时间
- GCT：垃圾回收消耗总时间，新生代+老年代
6. 老年代内存统计
命令：
jstat -gcoldcapacity 进程ID
5
参数含义：
- OGCMN：老年代最小容量
- OGCMX：老年代最大容量
- OGC：当前老年代大小
- OC：老年代大小
- YGC：年轻代垃圾回收次数
- FGC：老年代垃圾回收次数
- FGCT：老年代垃圾回收消耗时间
- GCT：垃圾回收消耗总时间
7. 元数据空间统计
命令
jstat -gcmetacapacity 进程ID
- MCMN:最小元数据容量
- MCMX：最大元数据容量
- MC：当前元数据空间大小
- CCSMN：最小指针压缩类空间大小
- CCSMX：最大指针压缩类空间大小
- CCSC：当前指针压缩类空间大小
- YGC：年轻代垃圾回收次数
- FGC：老年代垃圾回收次数
- FGCT：老年代垃圾回收消耗时间
- GCT：垃圾回收消耗总时间
8.整体运行情况
命令：
jstat -gcutil 进程ID
77
- S0：Survivor 1区当前使用比例
- S1：Survivor 2区当前使用比例
- E：Eden区使用比例
- O：老年代使用比例
- M：元数据区使用比例
- CCS：指针压缩使用比例
- YGC：年轻代垃圾回收次数
- YGCT：年轻代垃圾回收消耗时间
- FGC：老年代垃圾回收次数
- FGCT：老年代垃圾回收消耗时间
- GCT：垃圾回收消耗总时间 通过查询上面的参数来分析整个堆空间。
Archas排查线上故障
https://blog.csdn.net/wdays83892469/article/details/124829491?spm=1001.2014.3001.5502
参考资料：原文链接：https://blog.csdn.net/wdj_yyds/article/details/122442027