内存溢出,通俗的理解,就是你要求分配的内存超出了JVM能给你的,JVM不能满足需求,于是产生溢出。 为了便于理解,本文我们将使用一个案例来说明内存溢出。


首先,还是先看看本文的主要框架:


0fca8fd5946b9c8cb94d13a31cde5088.png

查看JVM内存情况d8686614383188b5a21eab5f19f030d9.png

 1public class PrintGCDetailsDemo {
2    public static void main(String[] args) {
3         //JVM最大堆空间
4        System.out.println("Xmx=" + Runtime.getRuntime().maxMemory() / 1024.0 / 1024 + "M");   
5        //JVM堆空闲空间
6        System.out.println("free mem=" + Runtime.getRuntime().freeMemory() / 1024.0 / 1024 + "M");   
7        //当前可用的总空间
8        System.out.println("total mem=" + Runtime.getRuntime().totalMemory() / 1024.0 / 1024 + "M");   
9    }
10}

运行上面代码就会输出对应JVM堆的内存情况。

1Xmx=1796.0M
2free mem=119.08892822265625M
3total mem=123.0M


内存溢出代码案例

我们先来看一个demo案例,代码如下:

 1@RestController
2public class GCController {
3
4    List<Object> strings = new ArrayList<>();
5
6    @GetMapping("/gc")
7    public String addObject() {
8        System.out.println("-------gc-------");
9        for (int i = 0; i < 1000000; i++){
10            try {
11                Thread.sleep(20);
12            } catch (InterruptedException e) {
13                e.printStackTrace();
14            }
15            int [] a=new int[500000];
16            //不断的想List中添加,不断的申请内存
17            strings.add(a);
18        }
19        return "ok";
20    }
21}

设置堆最大内存为10m,设置方式:-Xmx10m

然后在IDEA中设置

f613587dd0d72e19354d550a81848605.png

运行我们的Spring Boot项目,访问

http://localhost:8080/gc

不过一会儿就报异常了

534a9d71c3ba54f56ccd12e95f2171f4.png

这种 OOM 是一眼都能找到问题的点。这样看非常简单的。

但是,像在我们业务代码里可能就是因为某个while或者if条件判断导致OOM可能排查起来就没那么轻松了,因为你需要搞清除错误出在哪一段代码,还得清除是什么业务场景会执行到这样的代码里。


堆相关参数有哪些?d8686614383188b5a21eab5f19f030d9.png

以下是最常见堆JVM相关参数

-XX:PrintFlagsInitial: 查看所有参数的默认初始值

-XX:PrintFlagsFinal:查看所有的参数的最终值(可能会存在修改,不再是初始值)

-Xms: 初始堆空间内存(默认为物理内存的1/64)

-Xmx: 最大堆空间内存(默认为物理内存的1/4)

-Xmn: 设置新生代大小(初始值及最大值)

-XX:NewRatio: 配置新生代与老年代在堆结构的占比

-XX:SurvivorRatio:设置新生代中Eden和S0/S1空间的比例

-XX:MaxTenuringThreshold:设置新生代垃圾的最大年龄(默认15)

-XX:+PrintGCDetails:输出详细的GC处理日志

打印GC简要信息:① -XX:+PrintGC ② -verbose:gc

-XX:HandlePromotionFailure:是否设置空间分配担保

新生代内存过小d8686614383188b5a21eab5f19f030d9.png

参数设置,新生代设置为1m

-Xmx200m -Xms200m -Xmn1m -XX:+PrintGCDetails

继续访问上面的

http://localhost:8080/gc

然后继续看垃圾回收日志

ee3a853def2df4276826f28330d90b19.png

由于我们的新生代内存设置过小,所以上面代码一开始就进行Full GC了,接着就是新生代中没有足够的空间能够存储新的数据了。

jps工具

jsp查询系统内所有HotSpot进程,它位于java的bin目录下,在这个bin目录下有很多好用的工具,这里说说jps

de099dd0ca6af22b7d01d0921350e96f.png

最简单的使用

b537bfa031c7a1a917e75160924ba74c.png

jps -q只列出进程ID,其他都不列

d743d8f9a383e9462c619109a1546ade.png

jps -m列出代码传给main方法的类

f2496692d0cf5fafdbf683994c4569f1.png

jps -l输出当前运行主类的全称 ,jps只能看到类名,无法看到全限定类名,使用加参数 -l 就可以看到全限定类名

75238921690aa10bf9cd16fabb5b9aee.png

jps -v输出虚拟机进程启动时JVM参数

14f65a6729c6caa458a1c901be7c3939.png

jstat工具d8686614383188b5a21eab5f19f030d9.png

jstatJDK自带的一个轻量级小工具。全称“Java Virtual Machine statistics monitoring tool”,和jps一样,都在bin目录下;

070bb072fe087a21167c2bb74ec46ff9.png

主要利用JVM内建的指令对Java应用程序的资源和性能进行实时的命令行的监控,包括了对Heap size和垃圾回收状况的监控。可见,jstat是轻量级的、专门针对JVM的工具,非常适用。jstat工具特别强大,有众多的可选项,详细查看堆内各个部分的使用量,以及加载类的数量。使用时,需加上查看进程的进程id 。

我们常用查看GC信息命令

1jstat -gc pid 1000 10

表示查看进程pidGC信息,每一秒(1000毫秒)输出一次,输出10次。

4029608336b0acd5b6ef2f248fd33675.png

jstat -gc 参数说明

  • S0C:第一个幸存区的大小

  • S1C:第二个幸存区的大小

  • S0U:第一个幸存区的使用大小

  • S1U:第二个幸存区的使用大小

  • EC:伊甸园区的大小

  • EU:伊甸园区的使用大小

  • OC:老年代大小

  • OU:老年代使用大小

  • MC:方法区大小

  • MU:方法区使用大小

  • CCSC:压缩类空间大小

  • CCSU:压缩类空间使用大小

  • YGC:年轻代垃圾回收次数

  • YGCT:年轻代垃圾回收消耗时间

  • FGCFull Gc次数

  • FGCTFull Gc消耗时间

  • GCT:垃圾回收消耗总时间

查看gc发生的原因:

1jstat -gccause pid 1000 10

cefa4b11eddc87f3cf1c46a295c4711d.png

jstat -gcutil 5552 1000 20

4c859ee8adbd4914e8cb07e1bcf7cdb5.png

查看进程id的加载类信息 :jstat -class pid

e2b7c8b35b31697250933ee2f3dea346.png

总结

希望大家结合所学知识和JVM相关参数,自己抽时间也倒腾倒腾这些参数,这样便于更深刻的理解。

加油!趁年轻,再不加油就老咯~。