内存溢出,通俗的理解,就是你要求分配的内存超出了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
了,接着就是新生代中没有足够的空间能够存储新的数据了。
jsp
查询系统内所有HotSpot
进程,它位于java
的bin目录下,在这个bin目录下有很多好用的工具,这里说说jps
;
最简单的使用
jps -q
只列出进程ID,其他都不列
jps -m
列出代码传给main方法的类
jps -l
输出当前运行主类的全称 ,jps
只能看到类名,无法看到全限定类名,使用加参数 -l 就可以看到全限定类名
jps -v
输出虚拟机进程启动时JVM
参数
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次。
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
相关参数,自己抽时间也倒腾倒腾这些参数,这样便于更深刻的理解。
加油!趁年轻,再不加油就老咯~。
Copyright© 2013-2020
All Rights Reserved 京ICP备2023019179号-8