马克社区,马克吐温社区,马克java社区JVM04-JVM中内存溢出（包括内存泄露）以及其处理方法

JVM04-JVM中内存溢出（包括内存泄露）以及其处理方法

文章目录

    前言
    一些基本的设置说明
    堆内存溢出
    Java栈内存异常
    方法区和运行时常量池溢出
    直接内存溢出
    内存泄露
        内存泄露的定义：
        解决办法
    内存溢出的原因分析：
    线上内存溢出的处理方法
    总结

前言

上一篇我们介绍了JVM03–JVM垃圾收集机制的一些基本概念，这一篇介绍一下JVM中各种内存溢出（包括内存泄露）及其处理方法。
本文会按照JVM中内存划分来介绍各种内存溢出的例子。
一些基本的设置说明

为了模拟出内存溢出的效果，我们需要手动设置内存区域的内存大小，下面就是设置值部分设置值及其说明。
在这里插入图片描述

一个项目的启动设置

nohup java -Xms2048m -Xmx2048m -jar api.jar --spring.profiles.active=prod > log.file 2>&1 &

堆内存溢出

Java堆用于存储对象的实例，我们只要不断地创建对象，并且保证GC Roots到对象之间有可达路径来避免垃圾回收机制清除这些对象，那么随着对象数量的增加，总容量触及最大堆的容量限制后就会产生内存溢出。Java堆内存的OutOfMemoryError异常是实际应用中最常见的内存溢出异常情况。出现Java堆内存溢出时，异常堆栈信息“java.lang.OutOfMemoryError”会跟随进一步提示“Java heap space”。下面举个例子来模拟堆内存溢出。这里将-Xms和-Xmx都设置成20M，保证了Java堆内存不可扩展。然后，通过-XX:HeapDumpPath指定dump文件的保存位置。这里通过while循环不断的创建对象，然后保存到集合中。

/**

Java堆内存异常
VM Args:
//这两个参数保证了堆中的可分配内存固定为20M
-Xms20m
-Xmx20m

-XX:+HeapDumpOnOutOfMemoryError //自动生成dump文件
//文件生成的位置，作为生成在桌面的一个目录
-XX:HeapDumpPath=D:\srv\dump
*

@author xiang.wei
@date 2020/5/27 13:35
/
public class HeapOOM {
/*
- 创建一个内部类用于创建对象使用
  */
  static class OOMObject {
  }
public static void main(String[] args) {
List list = new ArrayList<>();
//无限的创建对象放在堆中
while (true) {
list.add(new OOMObject());
}
}
}

下面简单的说一下在Idea中设置应用运行内存的方法，我们只需要在 Run---->Edit Configurations—>找到需要设置的主类，然后在VM options中添加

-Xms20M -Xmx20M -Xmn20M -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=D:\srv\dump

如下图所示：

上面程序运行结果如下：

java.lang.OutOfMemoryError: Java heap space
Dumping heap to D:\srv\dump\java_pid23624.hprof …
Heap dump file created [28062091 bytes in 0.143 secs]
Exception in thread “main” java.lang.OutOfMemoryError: Java heap space
at com.jay.service.HeapOOM.main(HeapOOM.java:31)
Java HotSpot™ 64-Bit Server VM warning: MaxNewSize (20480k) is equal to or greater than the entire heap (20480k). A new max generation size of 19968k will be used.

我们可以看到程序生成了dump文件到指定目录，打开jvisualvm.exe工具导入heapDump文件，相应的说明如下图所示：

一共创建了802858个实例，消耗了 98.9%的运行内存。
切换到实例数如下图所示：
在这里插入图片描述

如何解决堆内存的OOM异常呢，首先需要确认内存中导致OOM的对象是否是必要的，也就是要先分清楚到底是出现了内存泄露（Memory Leak）还是内存溢出(Memory Overflow)。
Java栈内存异常

说完了Java堆内存异常，下面我们来看看Java栈内存异常，在实际开发中发生栈内存异常的情况比较少。Java栈内存异常发生的两种情况是：

如果线程请求的栈深度（栈深度：指目前虚拟机栈中没有出栈的方法帧）大于虚拟机所允许的最大深度，将抛出StackOverflowError异常。这种情况在递归的场景下可能会出现，如果在使用递归算法时没有控制好递归的跳出条件，就有可能会出现这种情况，下面的例子就是一个没有跳出条件的递归调用。根据前面说明，我们可以通过-Xss160k设置栈容量为160K。
如果虚拟机的栈内存允许动态扩展，当扩展容量无法申请到足够的内存时，将抛出OutOfMemoryError异常。
如下这个例子：

/**

VM Args:
设置栈容量为160K，默认1M
-Xss160k
@author xiang.wei
@date 2020/5/27 16:09
*/
public class JavaVMStackSOF {

private int stackLength = 1;

public void stackLeak() {
stackLength++;
System.out.println("*********栈的深度是:" + stackLength);
//递归调用
stackLeak();
}

public static void main(String[] args) throws Throwable {
JavaVMStackSOF oom = new JavaVMStackSOF();
try {
oom.stackLeak();
} catch (Exception e) {
throw e;
}
}
}

运行结果如下：

*********栈的深度是:1287
Exception in thread “main” java.lang.StackOverflowError
at sun.nio.cs.UTF_8.updatePositions(UTF_8.java:77)

可以看到，递归调用了1287次，栈容量不够用了。
默认的栈容量在正常的方法调用时，栈深度可以达到1000-2000深度，所以，一般的递归可以承受的住，如果代码中出现了StackOverflowError，首先需要检查代码，看看是不是递归写的不对。不能只是调参数。
当创建很多线程时，容易出现OOM（OutOfMemoryError），这时可以通过具体情况，减少最大堆容量，或者栈容量来解决问题。
线程数(最大栈容量)+最大堆值+其他内存（忽略不计或者一般不改动）=机器最大内存*
当线程数比较多时，且无法通过业务上减少线程数，再不换机器的情况下，我们只能把最大栈容量设置小一点，或者把最大堆值设置小一点。
方法区和运行时常量池溢出

由于运行时常量池是方法区的一部分，所以这两个区域的溢出测试可以放在一起进行。需要注意的是HotSpot从JDK7开始逐步“去永久代”的计划，并在JDK8中完全使用元空间代替永久代，使用"永久代"还是"元空间"来实现方法区，对程序的影响是不同的。
元空间与永久代之间最大的区别在于：元空间并不在虚拟机中，而是使用本地内存，因此，默认情况下元空间的大小仅受本地内存限制，但仍可以通过参数控制：
-XX:MetaspaceSize与-XX:MaxMetaspaceSize来控制大小。
方法区溢出也是一种常见的内存溢出异常，一个类如果要被垃圾收集器回收，要达成的条件是比较苛刻的。在经常运行时生成大量动态类的应用场景里，就应该特别关注这些类的回收状况，这类场景除了之前提到的程序使用了CGLib字节码增强和动态语言外，常见的还有：大量JSP或动态产生JSP文件的应用（JSP第一次运行时需要编译为Java类）、基于OSGI的应用（即使是同一个类文件，被不同的加载器加载也会被视为不同的类）。
方法区的主要职责是用于存放类型的相关信息，如类名、访问修饰符、常量池、字段描述、方法描述等。对于这部分区域的测试，基本的思路是运行时产生大量的类去填满方法区，直到溢出为止。
这是因为在调用CGLib创建代理时会生成动态代理类，即Class对象到Metaspace，所以while一下就出异常了。
下面这个例子就是通过设置元空间大小，然后，通过动态代理生成大量的类，来模拟元空间内存溢出的情况。

/**

在JDK8下测试方法区，所以设置了Metaspace的大小为固定的8M
-XX:MetaspaceSize=8m
-XX:MaxMetaspaceSize=8m
@author xiang.wei
@date 2020/5/27 17:29
*/
public class JavaMethodAreaOOM {
public static void main(String[] args) {
while (true) {
Enhancer enhancer = new Enhancer();
enhancer.setSuperclass(JOOMObject.class);
enhancer.setUseCache(false);
enhancer.setCallback((MethodInterceptor) (obj, method, objects, methodProxy) -> methodProxy.invokeSuper(obj,objects));
//无限创建动态代理，生成class对象
enhancer.create();
}
}
static class JOOMObject{}

运行结果：

Exception in thread “main” java.lang.OutOfMemoryError: Metaspace
at org.springframework.cglib.core.ReflectUtils.defineClass(ReflectUtils.java:538)
at org.springframework.cglib.core.AbstractClassGenerator.generate(AbstractClassGenerator.java:363)

直接内存溢出

直接内存导致的内存溢出，一个明显的特征是在Heap Dump文件中不会看见有什么明显的异常情况，如果发现内存溢出之后产生的Dump文件很小，而程序中又直接或者间接使用了DirectMemory（典型的的间接使用就是NIO）,那就可以考虑重点检查一下直接内存方面的原因了。
直接内存溢出的举例;

Exception in thread “main” java.lang.OutOfMemoryError
at sun.misc.Unsafe.allocateMemory(Native Method)

--------------------------------------------------------------------------------------------面试总结---------------------------------------------------------------------------------------------------------------------
内存泄露
内存泄露的定义：

内存泄露是指程序在申请内存时，无法释放已经申请的内存空间，这就造成了内存泄露，一次内存泄露似乎不会有大的影响，但是内存泄露堆积的后果就是内存溢出。
解决办法

资源性对象，使用完之后需要手动的close，例如：输入流InputStream等等。
集合容器中的内存泄露，我们通常把一些对象加入到集合容器中（例如：ArrayList）中，当我们不需要该对象时该对象时，并没有把它的引用从集合中清理掉，这样这个集合就会越来越大，如果这个集合是static的话，那情况就更加严重了，前面的HeapOOM就是这种情况，最终内存溢出。
使用ThreaLocal时，当Thread长时间不结束，存在大量废弃的ThreadLocal，而又不再添加新的ThreadLocal时会发生内存泄露。

内存溢出的原因分析：

内存中加载的数据量过于庞大，如一次从数据库中取出过多数据
集合中有对象的引用，使用完后未清空，产生了堆积，使得JVM不能回收
代码中存在死循环或者循环产生过多重复的对象实体
使用的第三方的软件的BUG。
启动参数内存值设定的过小。

线上内存溢出的处理方法

将内存对账的信息dump下来，使用：

jmap -dump:format=b,file=文件名 [pid]


将内存堆栈的信息导入VisualVM中进行分析。

总结

本文首先介绍了堆内存溢出（OutOfMemoryError）发生的场景以及处理方式，OutOfMemoryError发生的场景主要就是系统创建了大量的对象，并且这些对象是有效的（即保证GC Roots到对象之间有可达路径）。然后，介绍了栈内存异常（StackOverflowError）的发生场景以及处理方式，StackOverflowError发生的场景主要是线程调用栈深度超过了虚拟机运行的栈深度。最后，介绍了方法区的内存溢出。需要注意的是JDK1.8中完全移除了永久代，取而代之的是元空间。

作者：码农飞哥
微信公众号：码农飞哥

JAVA