JVM频繁GC内存溢出排查

清疚 2023-09-25 22:16 93阅读 0赞

# 前言 #

GC（Garbage collection）频繁和堆内存溢出原因简单来说是对象占用堆空间难以回收，新对象无法分配触发GC或者直接导致内存溢出，最终进程结束。

排查思路是先查看进程各种类型对象占用空间大小和比例，锁定占用空间较多的对象后再分析相关的程序是否有使用不当的地方。下文的侧重点是通过多种方式查看堆内存分布。

# 例子程序 #

先编译（javac FrequentFullGCSample.java）例子程序，执行下面的指令来创建JVM进程。

指定-Xms2M -Xmx2M来限制堆内存大小为 2兆，作为例子程序够用了；为了方便演示我们再加上这两个选项：-XX:+PrintCommandLineFlags打印有变动的JVM选项值；-XX:+PrintGCDetails打印垃圾回收的详细信息。

java -Xms2M -Xmx2M -XX:+PrintCommandLineFlags -XX:+PrintGCDetails FrequentFullGCSample
    复制代码

import java.util.LinkedList;
    import java.util.Queue;
    import java.util.concurrent.TimeUnit;
    
    public class FrequentFullGCSample {
    
        private static final Queue<Object> QUEUE = new LinkedList<>();
    
        public static void main(String[] args) throws InterruptedException {
            while (true) {
                QUEUE.offer(new Object());
                TimeUnit.MILLISECONDS.sleep(3);
            }
        }
    }
    复制代码

从控制台日志可以看到首先输出了部分有变动的JVM选项值：初始堆（-XX:InitialHeapSize）和最大堆（-XX:MaxHeapSize）大小都为2097152字节（B），也就是2兆（M）；使用了类指针压缩（-XX:+UseCompressedClassPointers）和对象指针压缩（-XX:+UseCompressedOops）。

在后面我们可以看到输出的GC日志信息，对象先分配在年轻代，空间占满开始频繁YGC（Young garbage collection）。

![format_png][]

经过几代回收之后，对象分代年龄增长转移到老年代，老年代空间逐渐占满开始频繁Full GC。

![format_png 1][]

由于例子程序新创建的对象都是强引用类型，不能定为垃圾，无法回收。经过频繁的Full GC无果后新对象无法分配到空间，报错内存溢出（java.lang.OutOfMemoryError）。从后面打印的各个分代的内存使用情况可以看出年轻代（def new generation）和老年代（tenured generation）占用比例接近100%。

![format_png 2][]

先通过jps找到我们的JVM进程ID

![format_png 3][]

# 查看堆中对象分配信息 #

## jmap -histo（推荐） ##

jmap是JDK自带的指令可以查看堆内存相关的信息。jmap -histo <Java进程ID>会列出进程中每个类型对象实例数量和占用空间大小按降序列出来，我们再加上head -10来查看前10行信息可以看到排名前几位的对象相关信息。

这种方式合适进程还在运行的时候用，统计输出的信息不多，对进程本身影响比较小。

jmap -histo 20091 | head -10
    复制代码

![format_png 4][]

## jmap -dump + Java VisualVM ##

jmap -dump可以将堆内存信息以二进制的方式转储到文件，格式为jmap -dump:format=b,file=<文件名> <Java进程ID>。

这种方式转储的数据比较多，当我们的JVM堆内存使用空间比较大的时候（比如上G大小）需要一定的时间，而且转储的过程中会影响进程运行。一般不建议这样做，除非JVM配置/使用的空间比较小。

jmap -dump:format=b,file=71976.dump 71976
    复制代码

![format_png 5][]

有了堆转储文件，我们找一个可以分析这个文件的工具来查看，这里我们用JDK自带的JVM图形化工具Java VisualVM。

# Mac在命令行输出下面命令打开
    /System/Library/Frameworks/JavaVM.framework/Versions/Current/Commands/jvisualvm
    
    # Windows在JDK中bin目录下
    复制代码

点击【文件】>【装入】，选择合适的类型后再选中我们的堆转储文件打开。

![format_png 6][]

装入后点击类，可以在图形化界面看到当时堆中各种类的实例数和大小。

![format_png 7][]

## 内存溢出时自动生成堆转储文件（推荐） ##

启动时增加一个JVM选项-XX:+HeapDumpOnOutOfMemoryError。默认文件会生成到当前目录下，名为java\_pid<进程ID>.hprof，可以通过选项-XX:HeapDumpPath=<目录>生成到指定的目录。再用Java VisualVM装入查看即可。

这种方式是比较推荐的，进程已经出问题要退出了，退出前能生成信息帮助我们事后分析。

java -Xms2M -Xmx2M \
    -XX:+PrintCommandLineFlags \
    -XX:+PrintGCDetails \
    -XX:+HeapDumpOnOutOfMemoryError FrequentFullGCSample
    复制代码

## Java VisualVM 远程监控 ##

java命令中多加几个选项启用远程监控。-Djava.rmi.server.hostname填本机IP地址；-Dcom.sun.management.jmxremote.port填远程访问使用的端口；其他两个是为了关闭鉴权不校验用户名密码。

进程开启监控肯定需要额外的工作，下发数据、网络交互等等，会影响到进程的运行，所以一般不用。但是可以用在测试的时候，压力测试同时监控，便于分析。

java -Xms2M -Xmx2M -XX:+PrintCommandLineFlags -XX:+PrintGCDetails \
    -Dcom.sun.management.jmxremote \
    -Dcom.sun.management.jmxremote.authenticate=false \
    -Dcom.sun.management.jmxremote.ssl=false \
    -Dcom.sun.management.jmxremote.port=1099 \
    -Djava.rmi.server.hostname=192.168.252.132 FrequentFullGCSample
    复制代码

双击【远程】，填好主机地址后点【确定】。

![format_png 8][]

右键点击刚刚配置出现的主机，选择【添加JMX】连接，填好端口号点【确定】。

![format_png 9][]

双击刚配置的JMX连接，点击【抽样器】>【内存】可以实时看到堆内存中各种对象的分配情况。

![format_png 10][]

# 总结 #

以上方式推荐的还是jmap -histo和内存溢出时自动转储，对进程本身影响比较小。

另外jmap -heap <Java进程ID>可以看堆内存相关的JVM配置和堆内存整体分配。

[format_png]: https://img-blog.csdnimg.cn/img_convert/18a5f313074b366ff687d8aca6dacc6c.webp?x-oss-process=image/format,png
[format_png 1]: https://img-blog.csdnimg.cn/img_convert/3693aed7f3b8f64715e3183b78bf3e18.webp?x-oss-process=image/format,png
[format_png 2]: https://img-blog.csdnimg.cn/img_convert/49e669571fca6754d86eff8a547a0628.webp?x-oss-process=image/format,png
[format_png 3]: https://img-blog.csdnimg.cn/img_convert/718c7fcea49f9d537c6f53b73ad0484d.webp?x-oss-process=image/format,png
[format_png 4]: https://img-blog.csdnimg.cn/img_convert/503735fada8774d8ddc7efb9d0659f1c.webp?x-oss-process=image/format,png
[format_png 5]: https://img-blog.csdnimg.cn/img_convert/8be0bb813dc54b92803e8d98823b7343.webp?x-oss-process=image/format,png
[format_png 6]: https://img-blog.csdnimg.cn/img_convert/939d9326ec94fbcce9f6d447078eb6b0.webp?x-oss-process=image/format,png
[format_png 7]: https://img-blog.csdnimg.cn/img_convert/e7876eab46d070f3b87948c827eec2b4.webp?x-oss-process=image/format,png
[format_png 8]: https://img-blog.csdnimg.cn/img_convert/a5920074cc36d51b82d8968e12d225cc.webp?x-oss-process=image/format,png
[format_png 9]: https://img-blog.csdnimg.cn/img_convert/2a8c8ad021cf5cf2872787fb79d4557a.webp?x-oss-process=image/format,png
[format_png 10]: https://img-blog.csdnimg.cn/img_convert/057d45b526a5f76d05f0a7b38a2be16b.webp?x-oss-process=image/format,png