排查 JVM 总是 full GC 的问题

有时候，full GC 过多，会占用大量的 CPU 资源，导致 JVM 发生过多的 STW 问题

我们开始写触发该场景的业务代码

import java.util.concurrent.TimeUnit;

/**
 * @author 594781919@qq.com
 * @date 2020/6/8
 **/
public class GcTest {
    public static void main(String[] args) throws InterruptedException {
        while (true) {
            byte[] data = new byte[1024 * 1024 * 10];
            TimeUnit.MILLISECONDS.sleep(1);
        }
    }
}

在服务器上执行代码

$ java -Xms15m -Xmx15m GcTest

查看服务器的执行情况

通过top命令，我们可以看到有条 java 命令占用了 70% 多的 CPU 资源。

然后我们使用top -Hp 14804可以查看该进程下的线程执行情况。
从图中我们可以发现，除了 java 命令占用了很多 CPU 资源外，还有个 VM Thread命令也占用了很多的 CPU 资源。

一般情况下，VM Thread 命令执行的就是 GC 操作。
我们通过一个命令查看 GC 情况：

$ jstat -gc 14804

通过查看，我们发现 FGC 发生了69000+ 次，说明进行了大量的 full GC 的操作。

这个时候我们就可以把堆的情况导出，进行分析：
执行的命令：jmap -dump:format=b,file=[文件路径/文件名.hprof] [进程ID]
这是我测试时执行的命令：

$ jmap -dump:format=b,file=/root/java/heap.hprof 14804

将heap.hprof文件拷贝到自己的电脑中，然后执行 JDK 自带的软件jdk1.8.0_202\bin\jvisualvm.exe

打开 jvisualvm.exe软件后，点击 “文件” => “装入”

选择我们刚才导出的heap.hprof文件

我们可以发现有一个类占用了大量的内存，然后我们就可以根据这个去业务代码查找创建大量该类实例的代码，进行修改。
如果要更快的查找到需要修改的代码，我们可以配合使用 jstack命令，查看目前正在运行的线程的栈信息，辅助我们去查找产生大量实例的位置。