一文搞懂堆外内存（模拟内存泄漏）

Java
333
0
0
2023-06-09
Java多线程入门到精通，小白也能快速入门
上一篇
树形结构！别再用递归实现了这才是最佳的方案；更快更强更好用
下一篇

一、前言

平时编程时，在 Java 中创建对象，实际上是在堆上划分了一块区域，这个区域叫 堆内内存 。

  • 使用这 -Xms -Xmx 来指定 新生代 和 老年代 空间大小的初始值和最大值，这初始值和最大值也被称为 Java 堆 的大小，即 堆内内存 大小。
  • 这个 堆内内存 完全受 JVM 管理 ， JVM 有垃圾回收机制，所以我们一般不必关系对象的内存如何回收。

剖开 JVM 内存模型，来看下其堆划分：

由图可知 Java8 使用元空间替代永久代且元空间放在堆外内存上，这是为啥？

  1. 类的元数据信息 常用到，在 GC 时回收效率偏低。
  2. 类的元数据信息 比较难以确定其大小，指定太小容易出现永久代溢出、指定太大则容易造成老年代溢出。

那什么是堆外内存？

Java 程序一般使用 -XX:MaxDirectMemorySize 来限制 最大堆外内存 。

还有个问题：堆外内存属于用户空间还是内核空间？ 用户空间。

（1）为什么需要堆外内存？

使用堆外内存，有这些好处：

  1. 直接使用堆外内存可以减少一次内存拷贝： 当进行网络 I/O 操作、文件读写时，堆内内存都需要转换为堆外内存，然后再与底层设备进行交互。
  2. 降低 JVM GC 对应用程序影响：因为堆外内存不受 JVM 管理。
  3. 堆外内存可以实现进程之间、 JVM 多实例之间的数据共享。

那我就有个问题：为什么使用堆外内存可以减少一次内存拷贝呢？

原因：当进行网络 I/O 操作或文件读写时，如果使用 堆内内存（ Heap byte Buffer ） ， JDK 会先创建一个 堆外内存（ DirectBuffer ） ，再去执行真正的读写操作。

具体原因是： 调用底层系统函数（ write 、 read 等），必须要求使用是 连续的 地址 空间 。

  1. 操作系统并不感知 JVM 的堆内存 ，而且 JVM 的内存布局与操作系统所分配的是不一样的，操作系统并不会按照 JVM 的行为来读写数据。
  2. 同一个对象的内存地址随着 JVM GC 的执行可能会随时发生变化 ，例如 JVM GC 的过程中会通过压缩来减少内存碎片，这就涉及对象移动的问题了。

当然使用堆外内存，有这些弊端：

  1. 排查 内存泄漏 问题相对困难： 因为堆外内存需要手动释放，不熟悉对应框架源码，可能稍有不慎就会造成应用程序内存泄漏。
  2. 对开发人员的基础技能要求高。

由此可以看出，如果想实现高效的 I/O 操作、 缓存 常用的对象、降低 JVM GC 压力，堆外内存是一个非常不错的选择。

（2）如何分配堆外内存？

Java 中堆外内存的分配方式有两种：

  1. NIO 类中的 Byte Buffer#allocateDirect
  2. Unsafe#allocateMemory

首先来看下 Java NIO 包中的 ByteBuffer 类的分配方式，使用方式如下： 

 // 分配M 堆外内存
ByteBuffer byteBuffer = ByteBuffer.allocateDirect( * 1024 * 1024);
// 释放堆外内存
((DirectBuffer) byteBuffer).cleaner().clean();

跟进 ByteBuffer.allocateDirect 源码，发现其中直接调用的 DirectByteBuffer 构造函数： 

 DirectByteBuffer(int cap) { 
    super(-, 0, cap, cap);
    boolean pa = VM.isDirectMemoryPageAligned();
    int ps = Bits.pageSize();
    long size = Math.max(L, (long)cap + (pa ? ps : 0));
    Bits.reserveMemory(size, cap);  // 注意这里会调用  System .gc();

    long base =;
    try {
        //. 真正分配堆外内存
        base = unsafe.allocateMemory(size);
    } catch ( OutOfMemory Error x) {
        Bits.unreserveMemory(size, cap);
        throw x;
    }
    unsafe.setMemory(base, size, (byte));
    if (pa && (base % ps !=)) {
        // Round up to page boundary
        address = base + ps - (base & (ps -));
    } else {
        address = base;
    }
    //. 用于回收堆外内存
    cleaner = Cleaner.create(this, new Deallocator(base, size, cap));
    att = null;
}

DirectByteBuffer 对象： 存放在堆内存里，仅仅包含堆外内存的地址、大小等属性。同时还会创建对应的 Cleaner 对象，通过 ByteBuffer 分配的堆外内存不需要手动回收，它可以被 JVM 自动回收。

当堆内的 DirectByteBuffer 对象被 GC 回收时， Cleaner 就会用于回收对应的堆外内存 。

真正分配堆外内存的逻辑还是通过 unsafe.allocateMemory(size)

Unsafe 是一个非常不安全的类，它用于执行内存访问、分配、修改等敏感操作，可以越过 JVM 限制的枷锁。 Unsafe 最初并不是为开发者设计的，使用它时虽然可以获取对底层资源的控制权，但也失去了安全性的保证，所以使用 Unsafe 一定要慎重。

在 Java 中是不能直接使用 Unsafe 的，但是可以通过反射获取 Unsafe 实例，使用方式如下所示： 

  private   static  Unsafe unsafe = null;

static {
    try {
        Field getUnsafe = Unsafe.class.getDeclaredField("theUnsafe");
        getUnsafe.setAccessible(true);
        unsafe = (Unsafe) getUnsafe.get(null);
    } catch (NoSuchField Exception  | IllegalAccessException e) {
        e.printStackTrace();
    }
}

获得 Unsafe 实例后，可以通过 allocateMemory 方法分配堆外内存， allocateMemory 方法返回的是内存地址，使用方法如下所示：

 // 分配M 堆外内存
long address = unsafe.allocateMemory( * 1024 * 1024);

// Unsafe#allocateMemory 所分配的内存必须自己手动释放，否则会造成内存泄漏
// 这也是 Unsafe 不安全的体现。
unsafe.freeMemory(address);

（3）如何回收堆外内存？

堆外内存回收，有两种方式：

  1. Full GC 时以及调用 System.gc() ： 通过 JVM 参数 -XX:MaxDirectMemorySize 指定堆外内存的上限大小，当堆外内存的大小超过该 阈值 时，就会触发一次 Full GC 进行清理回收，如果在 Full GC 之后还是无法满足堆外内存的分配，那么程序将会抛出 OOM 异常。
  2. 使用 unsafe.freeMemory(address); 来回收： DirectByteBuffer 在初始化时会创建一个 Cleaner 对象 ， Cleaner 内同时会创建 Deallocator ，调用 Deallocator#run() 来回收。

1）System.gc()触发

那就有个问题，什么时候会触发 System.gc() ？

ByteBuffer.allocateDirect 分配的过程中： 如果没有足够的空间分配堆外内存，在 Bits.reserveMemory 方法 中也会主动调用 System.gc() ，就会触发 Full GC （并不是马上执行）。
 // ByteBuffer.allocateDirect 直接调用 DirectByteBuffer 构造函数
DirectByteBuffer(int cap) { 
    ... 
    Bits.reserveMemory(size, cap);  // 注意这里会调用 System.gc();
    ...
}

Tips: 如果环境中设置了 -XX:+DisableExplicitGC ， System.gc() 会不起作用的。

所以依赖 System.gc() 并不是一个好办法。

2）Cleaner对象

通过前面堆外内存分配方式的介绍，我们知道 DirectByteBuffer 在初始化时会创建一个 Cleaner 对象，它会负责堆外内存的回收工作， 那么 Cleaner 是如何与 GC 关联起来的呢？

先来看下 Cleaner 的源码： 

 public class Cleaner  extends  java.lang.ref.PhantomReference<java.lang.Object> {
    private static final ReferenceQueue<Object> dummyQueue = new ReferenceQueue<>();
    // 双向 链表 
    private static sun.misc.Cleaner first;
    private sun.misc.Cleaner next;
    private sun.misc.Cleaner prev;

    private final java.lang.Runnable thunk;
    public  void  clean() {
        if (!remove(this)) // 把自己从链表上移除
            return;
        try {
            thunk.run(); // thunk 是 Deallocator
        } catch (final Throwable x) {
           // ... ...
        }
    }
}

可以看到 Cleaner 属于 PhantomReference 的子类， 那 Cleaner#clean() 执行是否跟 JVM GC 或 Reference 有关呢？

Tips ： Java 对象有四种引用方式， 强引用 StrongReference 、软引用 SoftReference 、弱引用 WeakReference 、虚引用 PhantomReference 。

这里先了解下 Reference 核心处理流程：

  1. JVM 垃圾收集器扫描到对象 O 可回收。
  2. 把对象 O 对应的 Reference 实例 R 添加到 PendingReference 链表中。
  3. 通知 ReferenceHandler 线程处理，最后完成清理逻辑。

下面是其源码： 

 // Reference.java， 部分代码省略
public  abstract  class Reference<T> {
    static {
        Thread handler = new ReferenceHandler(tg, "Reference  handler ");
        handler.setPriority(Thread.MAX_PRIORITY);
        handler.setDaemon(true);
        handler.start();
    }

    private static class ReferenceHandler extends Thread {
        public void run() {
            while (true) {
                tryHandlePending(true);
            }
        }
    }

    static boolean tryHandlePending(boolean waitForNotify) {
        Reference<Object> r;
        Cleaner c;
        try {
             synchronized  (lock) {
                if (pending != null) {
                    r = pending;
                    // 判断是否为 Cleaner
                    c = r  instanceof  Cleaner ? (Cleaner) r : null;
                    // unlink 'r' from 'pending' chain
                    pending = r.discovered;
                    r.discovered = null;
                } else {
                    // ... ...
                }
            }
        } catch (OutOfMemoryError x) {
            // 等待CG后的通知
            // ... ...
        } catch (InterruptedException x) {
            // ... ...
        }

        // 是为 Cleaner， 则调用 Cleaner.clean() 方法
        if (c != null) {
            c.clean();
            return true;
        }

        ReferenceQueue<? super Object> q = r.queue;
        if (q != ReferenceQueue.NULL) q.enqueue(r);
        return true;
    }
}

总结一下： 当 DirectByteBuffer 被回收的时候，会调用 Cleaner 的 clean() 方法来释放堆外内存。

拓展： Netty 的noCleaner策略

Netty 提供分配堆外内存时，不带 Cleaner 的方法： 

 // UnpooledByteBufAllocator#newDirectBuffer();
// 会创建 InstrumentedUnpooledUnsafeNoCleanerDirectByteBuf 不带 Cleaner

UnpooledUnsafeNoCleanerDirectByteBuf.allocateDirect(); // 创建内存
UnpooledUnsafeNoCleanerDirectByteBuf.freeDirect(); // 释放内存

Tips ： -XX:MaxDirectMemorySize 无法限制 Netty 中 noCleaner 策略的 DirectByteBuffer （堆外内存）的大小。

需要使用： -Dio.netty.maxDirectMemory ：

  • 用于限制 ** noCleaner 策略下 DirectByteBuffer **分配的最大堆外内存的大小
  • 如果该值为0，则使用 hasCleaner 策略，代码位于 PlatformDependent#incrementMemoryCounter() 方法中。

二、案例 堆外内存泄漏

（1）模拟堆外内存泄漏

模拟堆外内存泄漏，设置堆外内存大小 10MB ，代码如下：

 public class Test {
    // -XmxM -XX:MaxDirectMemorySize=10M -Xloggc:gc.log
    private static final int _MB = 10 * 1024 * 1024;
    public static void main(String[] args) throws Exception {
        List<ByteBuffer> list = new ArrayList<>();
        // 分配MB
        list.add(ByteBuffer.allocateDirect(_MB));
        list.add(ByteBuffer.allocateDirect(_MB));
    }
}

在 IDEA 里需要设置下 JVM 参数：

一文搞懂堆外内存（模拟内存泄漏）

运行果如下：

gc.log 日志如下：

 OpenJDK-Bit Server VM (25.162-b12) for  Linux -amd64 JRE (1.8.0_162-8u162-b12-1-b12), built on Mar 15 2018 17:19:50 by "buildd" with gcc 7.3.0
Memory:k page, physical 16306984k(1783576k free), swap 2097148k(7912k free)
CommandLine flags: -XX:InitialHeapSize= -XX:MaxDirectMemorySize=10485760 -XX:MaxHeapSize=10485760 -XX:+PrintGC -XX:+PrintGCTimeStamps -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseParallelGC 
.093: [GC (Allocation Failure)  2048K->701K(9728K), 0.0020135 secs]
.140: [GC (System.gc())  2147K->857K(9728K), 0.0039815 secs]
.144: [Full GC (System.gc())  857K->663K(9728K), 0.0069431 secs]

可以看到：分配堆外内存失败，会调用 System.gc() ，之后会触发 Full GC 。

运行上面代码同时，观察 Linux 中所占内存情况： 

 #. 先找到应用程序对应的 PID
$ jps
#. top 观察
$ top | grep

发现应用程序所占内存（ RES ）约 40MB ，远超堆内内存 10MB 和 堆外内存 10MB 。

为什么不用unsafe.allocateMemory()来模拟分配内存？

因为 Unsafe.allocateMemory() 是系统调用的 os::malloc 一个包装，并没有关心 VM 要求的内存限制，所以会绕过了 MaxDirectMemorySize 的限制。

可能会写这样的代码： 

 public class Test {
    private static final int _MB = 10 * 1024 * 1024;
    public static void main(String[] args) throws Exception {
        Field unsafeField = Unsafe.class.getDeclaredFields()[];
        unsafeField.setAccessible(true);
        Unsafe unsafe = (Unsafe) unsafeField.get(null);
        while (true) { // 会导致机子直接卡死，直至耗尽内存
            unsafe.allocateMemory(_MB);
        }
    }
}
// Exception in thread "main" java.lang.OutOfMemoryError
//    at sun.misc.Unsafe.allocateMemory(Native Method)
//    at org.fenixsoft.oom.DMOOM.main(DMOOM.java:)

最后抛出这个异常 Exception in thread “main” java.lang.OutOfMemoryError ，内存溢出才 kill 进程，且代价是期间机子卡死。

那为什么使用 ByteBuffer.allocateDirect() 就不会出现 unsafe 问题呢？

因为其每次分配内存，都会检查进程的内存占用情况并抛出异常。对应代码 Bits.reserveMemory(size, cap); 
 DirectByteBuffer(int cap) { 
    ...
    // 进行检测
    Bits.reserveMemory(size, cap);  // 注意这里会调用 System.gc();

    ... 
}

所以使用 ByteBuffer.allocateDirect() 相比更为安全些。

（2） 美团 堆外内存泄漏

WebSocket 断开连接后无法正常释放内存，之后添加 Packet packet = new Packet(PacketType.MSSAGE)` 就好了，框架能正常识别并释放内存了。

他的排查问题步骤，总结如下：

  1. 看监控：收到监控告警，去 监控平台 CAT 查看整个集群的各项指标。
  2. 猜一猜：怀疑可能出现问题的地方，并去 Review 代码。
  3. 硬头皮：查看日志文件，查看对应堆栈信息
  4. 上手段：代码中打点日志来进一步监控（ 注意：这里直接改生产代码，看生产日志 ）
  5. 模拟下：线下模拟，复现场景，线下验证
  6. 上生产：线上验证

以上就是所有学习啦， Have fun 。

Java多线程入门到精通，小白也能快速入门
上一篇
树形结构！别再用递归实现了这才是最佳的方案；更快更强更好用
下一篇