一文搞懂堆外内存（模拟内存泄漏）
一、前言
平时编程时，在 Java 中创建对象，实际上是在堆上划分了一块区域，这个区域叫堆内内存。
- 使用这
-Xms -Xmx来指定新生代和老年代空间大小的初始值和最大值，这初始值和最大值也被称为Java堆的大小，即 堆内内存大小。 - 这个堆内内存完全受
JVM管理，JVM有垃圾回收机制，所以我们一般不必关系对象的内存如何回收。
剖开 JVM 内存模型，来看下其堆划分：
由图可知 Java8 使用元空间替代永久代且元空间放在堆外内存上，这是为啥？
-
类的元数据信息常用到，在
GC时回收效率偏低。 - 类的元数据信息比较难以确定其大小，指定太小容易出现永久代溢出、指定太大则容易造成老年代溢出。
那什么是堆外内存？
堆外内存与堆内内存相对应，对于整个机器内存而言，除堆内内存以外部分即为堆外内存。
Java 程序一般使用 -XX:MaxDirectMemorySize 来限制最大堆外内存。
还有个问题：堆外内存属于用户空间还是内核空间？ 用户空间。
（1）为什么需要堆外内存？
使用堆外内存，有这些好处：
-
直接使用堆外内存可以减少一次内存拷贝： 当进行网络
I/O操作、文件读写时，堆内内存都需要转换为堆外内存，然后再与底层设备进行交互。 - 降低
JVM GC对应用程序影响：因为堆外内存不受JVM管理。 - 堆外内存可以实现进程之间、
JVM多实例之间的数据共享。
那我就有个问题：为什么使用堆外内存可以减少一次内存拷贝呢？
原因：当进行网络
I/O操作或文件读写时，如果使用堆内内存（HeapByteBuffer），JDK会先创建一个堆外内存（DirectBuffer），再去执行真正的读写操作。
具体原因是：调用底层系统函数（write、read等），必须要求使用是连续的地址空间。
-
操作系统并不感知
JVM的堆内存，而且JVM的内存布局与操作系统所分配的是不一样的，操作系统并不会按照JVM的行为来读写数据。 -
同一个对象的内存地址随着
JVM GC的执行可能会随时发生变化，例如JVM GC的过程中会通过压缩来减少内存碎片，这就涉及对象移动的问题了。
当然使用堆外内存，有这些弊端：
- 排查内存泄漏问题相对困难： 因为堆外内存需要手动释放，不熟悉对应框架源码，可能稍有不慎就会造成应用程序内存泄漏。
- 对开发人员的基础技能要求高。
由此可以看出，如果想实现高效的 I/O 操作、缓存常用的对象、降低 JVM GC 压力，堆外内存是一个非常不错的选择。
（2）如何分配堆外内存？
Java 中堆外内存的分配方式有两种：
-
NIO类中的ByteBuffer#allocateDirect -
Unsafe#allocateMemory
首先来看下 Java NIO 包中的 ByteBuffer 类的分配方式，使用方式如下：
// 分配 10M 堆外内存
ByteBuffer byteBuffer = ByteBuffer.allocateDirect(10 * 1024 * 1024);
// 释放堆外内存
((DirectBuffer) byteBuffer).cleaner().clean();
跟进 ByteBuffer.allocateDirect 源码，发现其中直接调用的 DirectByteBuffer 构造函数：
DirectByteBuffer(int cap) {
super(-1, 0, cap, cap);
boolean pa = VM.isDirectMemoryPageAligned();
int ps = Bits.pageSize();
long size = Math.max(1L, (long)cap + (pa ? ps : 0));
Bits.reserveMemory(size, cap); // 注意这里会调用 System.gc();
long base = 0;
try {
// 1\. 真正分配堆外内存
base = unsafe.allocateMemory(size);
} catch (OutOfMemoryError x) {
Bits.unreserveMemory(size, cap);
throw x;
}
unsafe.setMemory(base, size, (byte) 0);
if (pa && (base % ps != 0)) {
// Round up to page boundary
address = base + ps - (base & (ps - 1));
} else {
address = base;
}
// 2\. 用于回收堆外内存
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 (NoSuchFieldException | IllegalAccessException e) {
e.printStackTrace();
}
}
获得 Unsafe 实例后，可以通过 allocateMemory 方法分配堆外内存，allocateMemory 方法返回的是内存地址，使用方法如下所示：
// 分配 10M 堆外内存
long address = unsafe.allocateMemory(10 * 1024 * 1024);
// Unsafe#allocateMemory 所分配的内存必须自己手动释放，否则会造成内存泄漏
// 这也是 Unsafe 不安全的体现。
unsafe.freeMemory(address);
（3）如何回收堆外内存？
堆外内存回收，有两种方式：
-
Full GC时以及调用System.gc()： 通过JVM参数-XX:MaxDirectMemorySize指定堆外内存的上限大小，当堆外内存的大小超过该阈值时，就会触发一次Full GC进行清理回收，如果在Full GC之后还是无法满足堆外内存的分配，那么程序将会抛出OOM异常。 -
使用
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 核心处理流程：
-
JVM垃圾收集器扫描到对象O可回收。 -
把对象
O对应的Reference实例R添加到PendingReference链表中。 -
通知
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 {
// -Xmx10M -XX:MaxDirectMemorySize=10M -Xloggc:gc.log
private static final int _10MB = 10 * 1024 * 1024;
public static void main(String[] args) throws Exception {
List<ByteBuffer> list = new ArrayList<>();
// 分配 20MB
list.add(ByteBuffer.allocateDirect(_10MB));
list.add(ByteBuffer.allocateDirect(_10MB));
}
}
在 IDEA 里需要设置下 JVM 参数：
运行果如下：
gc.log 日志如下：
OpenJDK 64-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: 4k page, physical 16306984k(1783576k free), swap 2097148k(7912k free)
CommandLine flags: -XX:InitialHeapSize=10485760 -XX:MaxDirectMemorySize=10485760 -XX:MaxHeapSize=10485760 -XX:+PrintGC -XX:+PrintGCTimeStamps -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseParallelGC
0.093: [GC (Allocation Failure) 2048K->701K(9728K), 0.0020135 secs]
0.140: [GC (System.gc()) 2147K->857K(9728K), 0.0039815 secs]
0.144: [Full GC (System.gc()) 857K->663K(9728K), 0.0069431 secs]
可以看到：分配堆外内存失败，会调用 System.gc()，之后会触发 Full GC。
运行上面代码同时，观察 Linux 中所占内存情况：
# 1\. 先找到应用程序对应的 PID
$ jps
# 2\. top 观察
$ top | grep 25131
发现应用程序所占内存（ RES）约 40MB，远超堆内内存 10MB 和 堆外内存 10MB。
为什么不用 unsafe.allocateMemory() 来模拟分配内存？
因为 Unsafe.allocateMemory() 是系统调用的os::malloc一个包装，并没有关心 VM 要求的内存限制，所以会绕过了 MaxDirectMemorySize 的限制。
可能会写这样的代码：
public class Test {
private static final int _10MB = 10 * 1024 * 1024;
public static void main(String[] args) throws Exception {
Field unsafeField = Unsafe.class.getDeclaredFields()[0];
unsafeField.setAccessible(true);
Unsafe unsafe = (Unsafe) unsafeField.get(null);
while (true) { // 会导致机子直接卡死，直至耗尽内存
unsafe.allocateMemory(_10MB);
}
}
}
// Exception in thread "main" java.lang.OutOfMemoryError
// at sun.misc.Unsafe.allocateMemory(Native Method)
// at org.fenixsoft.oom.DMOOM.main(DMOOM.java:20)
最后抛出这个异常 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)` 就好了，框架能正常识别并释放内存了。
他的排查问题步骤，总结如下：
- 看监控：收到监控告警，去监控平台
CAT查看整个集群的各项指标。 - 猜一猜：怀疑可能出现问题的地方，并去
Review代码。 - 硬头皮：查看日志文件，查看对应堆栈信息
- 上手段：代码中打点日志来进一步监控（注意：这里直接改生产代码，看生产日志）
- 模拟下：线下模拟，复现场景，线下验证
- 上生产：线上验证
以上就是所有学习啦，Have fun。
