0
点赞
收藏
分享

微信扫一扫

一文搞懂堆外内存(模拟内存泄漏)

一、前言

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

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

剖开 ​​JVM​​ 内存模型,来看下其堆划分:

一文搞懂堆外内存(模拟内存泄漏)_java

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

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

那什么是堆外内存?

堆外内存与堆内内存相对应,对于整个机器内存而言,除堆内内存以外部分即为堆外内存

一文搞懂堆外内存(模拟内存泄漏)_java_02


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

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

(1)为什么需要堆外内存?

使用堆外内存,有这些好处:

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

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

原因:当进行网络 ​​I/O​​操作或文件读写时,如果使用堆内内存(​​HeapByteBuffer​​),​​JDK​​ 会先创建一个堆外内存(​​DirectBuffer​​),再去执行真正的读写操作。

具体原因是:调用底层系统函数(​​write​​、​​read​​等),必须要求使用是连续的地址空间

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

当然使用堆外内存,有这些弊端:

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

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

(2)如何分配堆外内存?

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

  1. ​NIO​​类中的ByteBuffer#allocateDirect
  2. ​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;
}

一文搞懂堆外内存(模拟内存泄漏)_java_03

​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)如何回收堆外内存?

堆外内存回收,有两种方式:

  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 线程处理,最后完成清理逻辑。

一文搞懂堆外内存(模拟内存泄漏)_内存泄漏_04

下面是其源码:

// 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​​ 参数:

一文搞懂堆外内存(模拟内存泄漏)_内存泄漏_05

运行果如下:


一文搞懂堆外内存(模拟内存泄漏)_java_06

​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

一文搞懂堆外内存(模拟内存泄漏)_java_07

发现应用程序所占内存( ​​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)` 就好了,框架能正常识别并释放内存了。

他的排查问题步骤,总结如下:

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

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

举报

相关推荐

0 条评论