JVM04-JVM内存泄露的场景以及排查
前言
这一篇介绍一下JVM中各种内存溢出及其处理方法。 本文会按照JVM中内存划分来介绍各种内存溢出的例子。
一些基本的设置说明
为了模拟出内存溢出的效果，我们需要手动设置内存区域的内存大小，下面就是设置值部分设置值及其说明。
分类 | 选项 | 说明 |
|---|---|---|
虚拟机栈 | -Xss | 每个线程的栈大小 |
堆空间 | -Xms | 启动JVM时的初始堆大小 |
堆空间 | -Xmx | 堆空间最大值 |
新生代空间 | -XX:NewRatio | 新生代与老年代的比例 |
新生代空间 | -XX:NewSize | 新生代大小 |
新生代空间 | -XX:SurvivorRation | Eden区域SurvivorRation区的比例 |
永久代空间 | -XX:PermSize | 启动JVM时的初始永久代大小 |
永久代空间 | -XX:MaxPermSize | 永久代空间最大值 |
元空间 | -XX:MetaspaceSize | 指定元空间的初始空间大小，以字节为单位，达到该值就会触发垃圾收集进行类型卸载，同时收集器会对该值进行调整；如果释放了大量的空间，就适当降低该值；如果释放了很少的空间，那么在不超过 -XX:MaxMetaspaceSize 的情况下，适当提高该值。 |
元空间 | -XX:MaxMetaspaceSize | 设置元空间最大值，默认是-1，即不限制，或者说只受限于本地内存大小 |
元空间 | -XX:MaxMetaspaceFreeRatio | 在垃圾收集之后控制最小的元空间剩余容量的百分比，可减少因为元空间不足导致的垃圾收集的频率 |
堆内存溢出
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<OOMObject> 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(TM) 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)
总结
本文首先介绍了堆内存溢出（OutOfMemoryError）发生的场景以及处理方式，OutOfMemoryError发生的场景主要就是系统创建了大量的对象，并且这些对象是有效的（即保证GC Roots到对象之间有可达路径）。然后，介绍了栈内存异常（StackOverflowError）的发生场景以及处理方式，StackOverflowError发生的场景主要是线程调用栈深度超过了虚拟机运行的栈深度。最后，介绍了方法区的内存溢出。需要注意的是JDK1.8中完全移除了永久代，取而代之的是元空间。
腾讯云开发者
