【JVM】如何定位、解决内存泄漏和溢出

1.概述

常见的几种JVM内存溢出的场景如下：

Java堆溢出： 错误信息: java.lang.OutOfMemoryError: Java heap space 原因：Java对象实例在运行时持续创建，但不再使用的对象没有及时被垃圾回收器回收，导致堆内存耗尽。 解决方案：增加堆内存大小(-Xms和-Xmx参数)，优化对象生命周期管理，减少不必要的大对象或者长时间存在的临时对象。

永久代/元空间溢出（取决于Java版本）： 在Java 8及以前版本中，永久代存储类信息、常量池、静态变量等数据，若空间不足会抛出java.lang.OutOfMemoryError: PermGen space错误。 在Java 8之后，永久代已被元空间取代，元空间直接使用本地操作系统内存，可能出现java.lang.OutOfMemoryError: Metaspace。 解决方案：增大永久代或元空间的大小，检查代码是否有大量动态加载类或者反射操作生成过多类信息的情况。

栈空间溢出： 错误信息: java.lang.StackOverflowError 原因：递归调用过深或线程栈帧过大，导致线程栈空间耗尽。 解决方案：调整栈的大小(-Xss参数)，改进算法避免深度递归，合理控制线程数量或每个线程栈的大小。

首先栈溢出定位很简单，直接异常栈就会告诉，去调整代码逻辑即可。这里着重要聊一下的是元空间溢出和堆溢出。

元空间溢出

JDK1.8及其以后版本，元空间替代了永久代，其主要用于存储类的元数据信息，包括类的结构信息（如字段、方法、接口、常量池等）、运行时常量池、方法字节码、静态变量等。也就是说类被加载了，其相关信息就会存在元空间中。

此处也许有些读者会有疑问：

类是要在被用到的时候才会加载，也就是一般我们new对象的时候对应的类才会被加载，那么存在元空间在堆之前被撑爆的情况吗？

答：

当然是存在的，只要你的元空间比你的堆小，或者频繁用Class.forName()、ClassLoader.loadClass()等反射的手法来加载类，但是不new对象，也能把元空间撑爆了。

元空间溢出其实是比较难遇见的，但是定位方法其实不难，直接代码全局搜Class.forName之类的语法基本就能定位元凶。

接下来本文要讲的重点是生产中最容易遇见的一种JVM内存溢出——堆溢出，以及比堆溢出藏得更深的隐形杀手——内存泄漏，这两者如何定位以及解决。

2.堆溢出、内存泄定位及解决办法

2.1.示例代码

直接的堆溢出从异常栈信息里是能看出哪里造成的OOM，很容易定位：

难定位的是哪种？怕的是内存泄漏，也就是堆还没有撑爆，但是就是在要爆不爆之间徘徊，造成频繁的GC，由于GC的时候是要”Stop The World“，会暂停所有JAVA线程的工作，这自然会浪费CPU资源，外界的感知就是”变慢了“。这里我们详细的来聊一聊如何定位内存泄漏的问题。

测试代码：

//定义一个类，该类中一旦调用一个方法，就会持续让List持有一个个1024KB大小的内存空间，但是又不会直接撑爆heap
import java.lang.management.ManagementFactory;
import java.lang.management.MemoryMXBean;
import java.util.ArrayList;
​
public class MyUser {
    private Byte[] bytes;
​
    ArrayList<byte[]> list = new ArrayList();
​
    public static final int OBJECT_SIZE = 1024 * 1024; // 每个对象占用1MB空间
    public static final double HEAP_UTILIZATION_RATIO = 0.8; // 目标堆利用率
​
    public MyUser(){}
​
    public void callTest(){
        try {
            MemoryMXBean memoryMxBean = ManagementFactory.getMemoryMXBean();
            long maxMemory = Runtime.getRuntime().maxMemory();
​
            while (true) {
                // 检查当前堆内存使用情况，如果已超过目标利用率，则退出循环
                long currentHeapUsage = memoryMxBean.getHeapMemoryUsage().getUsed();
                if ((double) currentHeapUsage / maxMemory >= HEAP_UTILIZATION_RATIO) {
                    System.out.println("当前堆内存使用率达到目标利用率，程序即将退出...");
                    break;
                }
​
                // 创建一个大对象
                byte[] largeObject = new byte[OBJECT_SIZE];
                // 将大对象添加到列表中
                list.add(largeObject);
​
                // 添加一个延时，模拟其他操作，便于观察
                Thread.sleep(100); // 等待100毫秒
​
                // 可以在此处添加额外的日志输出或监控代码，用于记录GC信息和内存状态
            }
​
            // 清理资源，防止后续分析时误判
            list.clear();
        } catch (InterruptedException e) {
            throw new RuntimeException(e);
        }
    }
}
​
//用junit开始测试
@Test
public void test02() throws Exception{
  MyUser myUser = new MyUser();
  myUser.callTest();

2.2.抓堆快照

运行上面的示例代码，打开jvisualVM，开始监控程序，可以看到：

垃圾回收是有在进行的，而且频率不低，但是堆的大小一直在扩，被占用率一直在攀升，说明并没有被回收掉，存在严重的内存泄露。

这时候就需要把堆的dump抓下来看看了。右上角有抓heap dump的选项。

2.3.分析堆快照

通过MAT看看了，看看到底是有哪些东西占着内存一直没被回收掉。

MAT是eclipse旗下的一款heap的分析工具，可以用来专门分析heap dump。下载地址：

Eclipse Memory Analyzer | projects.eclipse.org

MAT和JDK有版本适配关系！千万别下错了，作者用的JDK，下载的1.8.1版本：

还要注意下载的安装包和操作系统之间也是有严格的适配关系的，作者第一次就下成了x86而不是x86_64，确定好自己的操作系统平台下对应的：

用MAT打开抓下来的heap dump：

工具会分析显示除怀疑内存泄漏的地方：

其实从饼状图上已经可以看出端倪，饼状图显示了可能存在内存泄漏的对象和该对象持有的内存的对比，这个对象自身占的内存大小只有浅灰色的一小条，但是其持有的内存居然达到了300多MB，很明显的内存泄漏的情况。

我们初步断定了存在内存泄漏，接下来当然是要定位具体位置，然后才好解决它。

展开详细信息，可以看到怀疑是Main线程上的一个MyUser类型里面的一个类型为ArrayList名叫list的成员变量造成了内存泄漏：

接下来去看这里的代码逻辑就行了。