那个小白还没搞懂内存溢出，只能用案例说给他听了

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

首先，还是先看看本文的主要框架：

查看JVM内存情况

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中设置

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

http://localhost:8080/gc

不过一会儿就报异常了

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

但是，像在我们业务代码里可能就是因为某个while或者if条件判断导致

OOM

可能排查起来就没那么轻松了，因为你需要搞清除错误出在哪一段代码，还得清除是什么业务场景会执行到这样的代码里。

堆相关参数有哪些？

以下是最常见堆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

：是否设置空间分配担保

新生代内存过小

参数设置,新生代设置为

1m

-Xmx200m -Xms200m -Xmn1m -XX:+PrintGCDetails

继续访问上面的

http://localhost:8080/gc

然后继续看垃圾回收日志

由于我们的新生代内存设置过小，所以上面代码一开始就进行

Full GC

了，接着就是新生代中没有足够的空间能够存储新的数据了。

jps工具

jsp

查询系统内所有

HotSpot

进程，它位于

java

的bin目录下，在这个bin目录下有很多好用的工具，这里说说

jps

；

最简单的使用

jps -q

只列出进程ID，其他都不列

jps -m

列出代码传给main方法的类

jps -l

输出当前运行主类的全称 ，

jps

只能看到类名，无法看到全限定类名，使用加参数 -l 就可以看到全限定类名

jps -v

输出虚拟机进程启动时

JVM

参数

jstat工具

jstat

是

JDK

自带的一个轻量级小工具。全称

“Java Virtual Machine statistics monitoring tool”

，和

jps

一样，都在bin目录下；

主要利用

JVM

内建的指令对Java应用程序的资源和性能进行实时的命令行的监控，包括了对Heap size和垃圾回收状况的监控。可见，

jstat

是轻量级的、专门针对

JVM

的工具，非常适用。jstat工具特别强大，有众多的可选项，详细查看堆内各个部分的使用量，以及加载类的数量。使用时，需加上查看进程的进程id 。

我们常用查看

GC

信息命令

1jstat -gc pid 1000 10

表示查看进程

pid

的

GC

信息，每一秒（1000毫秒）输出一次，输出10次。

jstat -gc 参数说明

• S0C

  ：第一个幸存区的大小

• S1C

  ：第二个幸存区的大小

• S0U

  ：第一个幸存区的使用大小

• S1U

  ：第二个幸存区的使用大小

• EC

  ：伊甸园区的大小

• EU

  ：伊甸园区的使用大小

• OC

  ：老年代大小

• OU

  ：老年代使用大小

• MC

  ：方法区大小

• MU

  ：方法区使用大小

• CCSC

  :压缩类空间大小

• CCSU

  :压缩类空间使用大小

• YGC

  ：年轻代垃圾回收次数

• YGCT

  ：年轻代垃圾回收消耗时间

• FGC

  ：

  Full Gc

  次数

• FGCT

  ：

  Full Gc

  消耗时间

• GCT

  ：垃圾回收消耗总时间

查看

gc

发生的原因：

1jstat -gccause pid 1000 10

jstat -gcutil 5552 1000 20

查看进程id的加载类信息 ：

jstat -class pid

总结

希望大家结合所学知识和

JVM

相关参数，自己抽时间也倒腾倒腾这些参数，这样便于更深刻的理解。

加油！趁年轻，再不加油就老咯~。