1. ByteBuffer 堆外内存介绍
在介绍OOM那篇文章中，对堆外内存进行了介绍，就直接把它复制过来；
ByteBuffer和DirectByteBuffer：
-
ByteBuffer：字节缓冲区，它有两种实现：
-
HeapByteBuffer：使用jvm堆内存的字节缓冲区；（对应 ByteBuffer源码中的 allocate()方法）
-
DirectByteBuffer：使用堆外内存，不受jvm堆大小限制；（对应 ByteBuffer源码中的allocateDirect()方法）
-
DirectByteBuffer：ByteBuffer对于使用堆外内存的实现，堆外内存直接使用unsafe方法请求堆外内存空间，读写数据；
-
源码：
public abstract class ByteBuffer extends Buffer implements Comparable<ByteBuffer> {
// ... 省略
public static ByteBuffer allocateDirect(int capacity) {
return new DirectByteBuffer(capacity);
}
// ... 省略
}
DirectByteBuffer与堆外内存的关系：
- 我们使用allocateDirect()方法生成的DirectByteBuffer对象，本身是存储在jvm堆中的，但是会在堆外内存中划分一块内存区域与这个对象关联起来；
- 在YGC或者FGC 回收 DirectByteBuffer对象的时候，会通过虚引用（对虚引用不了解的可以查看前面的文章）来释放它关联的堆外内存空间（由Cleaner类实现）；
- Java NIO 在每次分配堆外内存会进行判断，如果堆外内存空间不足时，使用 System.gc() 尝试释放内存，再次进行判断；
堆外内存空间大小设置：
- jvm参数指定堆外内存大小：-XX:MaxDirectMemorySize=512m;
- 但是如果没有手动指定时，用我们前面介绍的获取jvm参数的默认值命令：java -XX:+PrintFlagsFinal -version | grep MaxDirectMemorySize获取到的大小为0；
其实它这里是使用了VM类中代码来指定的大小：
public class VM {
private static long directMemory = 64 * 1024 * 1024;
public static long maxDirectMemory() {
return directMemory;
}
}
也就是说堆外内存默认大小为64M；如果指定了jvm参数，就使用指定的大小值；
2. ByteBuffer 堆外内存申请、释放（源码分析）
2.1 堆外内存申请
ByteBuffer byteBuffer = ByteBuffer.allocateDirect(1 * 1024 * 1024);
public static ByteBuffer allocateDirect(int capacity) {
return new DirectByteBuffer(capacity);
}
在使用ByteBuffer的静态方法allocateDirect()申请内存时，会使用 DirectByteBuffer类的构造方法创建一个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));
// 判断是否有足够的空间可供申请
// size：根据是否按页对齐，得到的真实需要申请的内存大小
// cap：用户指定需要的内存大小(<=size)
Bits.reserveMemory(size, cap);
long base = 0;
try {
// 调用 UNsafe方法申请内存
base = unsafe.allocateMemory(size);
} catch (OutOfMemoryError x) {
// 申请失败，释放内存
Bits.unreserveMemory(size, cap);
throw x;
}
// 初始化内存空间为0
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;
}
// 使用 Cleaner机制注册内存回收处理函数
cleaner = Cleaner.create(this, new Deallocator(base, size, cap));
att = null;
}
在使用构造方法申请内存时，首先要判断是否有足够的内存空间可供申请，如果有空间可以申请，则更新对应的变量；如果不够需要先调用GC，如果还不够则抛出OOM；
static void reserveMemory(long size, int cap) {
if (!memoryLimitSet && VM.isBooted()) {
// 获取最大可以申请的对外内存大小，默认值是64MB
// 可通过jvm参数-XX:MaxDirectMemorySize=<size>设置这个大小
maxMemory = VM.maxDirectMemory();
memoryLimitSet = true;
}
// optimist!
// 尝试去预订空间，如果空间足够，则直接返回true
if (tryReserveMemory(size, cap)) {
return;
}
final JavaLangRefAccess jlra = SharedSecrets.getJavaLangRefAccess();
// retry while helping enqueue pending Reference objects
// which includes executing pending Cleaner(s) which includes
// Cleaner(s) that free direct buffer memory
// 可能 Cleaner会释放空间，进行重试，继续尝试预订空间
while (jlra.tryHandlePendingReference()) {
if (tryReserveMemory(size, cap)) {
return;
}
}
// trigger VM's Reference processing
// 还不够的话，在这里调用 GC，进行一次空间回收，释放指向了堆外内存的引用
System.gc();
// a retry loop with exponential back-off delays
// (this gives VM some time to do it's job)
// 通过一个带sleep的延时循环来继续尝试预订空间，预订成功则返回；
// 如果超过 MAX_SLEEPS 次数还未成功，直接抛出 "Direct buffer memory" 异常
boolean interrupted = false;
try {
long sleepTime = 1;
int sleeps = 0;
while (true) {
if (tryReserveMemory(size, cap)) {
return;
}
if (sleeps >= MAX_SLEEPS) {
break;
}
if (!jlra.tryHandlePendingReference()) {
try {
Thread.sleep(sleepTime);
sleepTime <<= 1;
sleeps++;
} catch (InterruptedException e) {
interrupted = true;
}
}
}
// no luck
// 几次重试预订都还不够的话，抛出 OOM
throw new OutOfMemoryError("Direct buffer memory");
} finally {
if (interrupted) {
// don't swallow interrupts
Thread.currentThread().interrupt();
}
}
}
在执行完这个方法之后，也就是有空间可以申请了，就开始申请空间：
try {
base = unsafe.allocateMemory(size);
} catch (OutOfMemoryError x) {
Bits.unreserveMemory(size, cap);
throw x;
}
allocateMemory()这个方法是通过unsafe通过JNI调用C的malloc来申请内存的；
2.2 堆外内存释放
在上面申请完堆外内存之后，注册了一个 Cleaner的内存回收对象：
cleaner = Cleaner.create(this, new Deallocator(base, size, cap));
这里是因为 DirectByteBuffer对象本身在堆内，会被jvm的GC正常回收掉；但是跟DirectByteBuffer关联的堆外内存区域就不会被GC回收掉了，所以需要一个机制，来在DirectByteBuffer被回收时，同时回收掉它在堆外申请的内存；
对于一个对象在被回收时，如果需要做一些额外的工作，java提供了两个特性来实现：
- 在finalize()方法中实现一些在对象被回收前的自定义操作（Java官方不推荐）；
- 通过虚引用来处理对象被回收后的自定义操作（存在虚引用的对象被GC回收时会收到一个系统通知）；
在堆外内存的释放这里，java采用的是虚引用的方法；并且提供了一个 Cleaner 类来简化这些操作，Cleaner是 PhantomReference的子类，可以在 PhantomReference被加入 ReferenceQueue队列的时候，触发对应的Runnable回调方法；
new Deallocator(base, size, cap);
这里的Deallocator就是一个实现了 Runnable接口的类：
private static class Deallocator implements Runnable {
private static Unsafe unsafe = Unsafe.getUnsafe();
private long address;
private long size;
private int capacity;
private Deallocator(long address, long size, int capacity) {
assert (address != 0);
this.address = address;
this.size = size;
this.capacity = capacity;
}
public void run() {
if (address == 0) {
// Paranoia
return;
}
unsafe.freeMemory(address);
address = 0;
Bits.unreserveMemory(size, capacity);
}
}
可以看到，它重写的 run()方法里面去调用了unsafe方法释放了内存并重置了统计变量；
所以，DirectByteBuffer 就是使用 Cleaner机制，把它自身当做一个虚引用对象来创建了一个 PhantomReference；所以当它本身被GC时，会添加到引用队列中；
然后通过对这个引用队列的监测，来调用它里面的对象的实现了 Runnable接口的Deallocator类的 run()方法，来实现堆外内存的释放。
3. 什么情况会发生 堆外内存 OOM
通过上面的介绍，我们知道了堆外内存的分配和回收的具体实现，那什么情况下会发生堆外内存不够，甚至OOM呢？
1、 如果系统瞬时承受了大量的并发请求，创建了大量的DirectByteBuffer，并且处理又慢，没法及时被GC掉，自然堆外内存不会被释放，然后就导致堆外内存溢出了；
2、 由于系统的jvm内存区域划分不够合理，在发生了Eden区的YGC之后，Survivor区放不下存活的对象，这些存活对象就会进入老年代；
-
然而正常来说老年代会很久发生一次FGC，也就是说，进入了老年代的 DirectByteBuffer 对象很久都不会被回收，自然堆外内存不会被释放，然后就导致堆外内存溢出了； 3、 对于第2种情况，其实jvm已经考虑到了；所以它才在申请内存不够时，会代码调用一次System.gc()来手动触发GC；
-
但是，如果你使用了
-XX:+DisableExplicitGC参数，来关闭了显示GC呢； -
所以，如果使用了
-XX:+DisableExplicitGC参数来关闭了显示GC，发生第2种情况的时候，就会导致 堆外内存溢出了；
4. 模拟 堆外内存 OOM
4.1 模拟1
/**
*
* 直接内存溢出
*
* jvm options：
* -XX:MaxDirectMemorySize=100m -verbose:gc -XX:+PrintGCDetails
*/
public class DirectByteBufferOomDemo {
public static void main(String[] args) {
int count = 0;
List<ByteBuffer> list = new ArrayList<>();
while (true) {
ByteBuffer byteBuffer = ByteBuffer.allocateDirect(1 * 1024 * 1024);
list.add(byteBuffer);
System.out.println("当前创建了 " + (++count) + "M 的对象");
}
}
}
代码很简单，就在一个死循环里面一直申请大小为1M的 DirectByteBuffer 对象，然后加入list，也就是有一个list一直持有它的引用，不会被GC掉；
然后使用了 -XX:MaxDirectMemorySize=100m指定堆外内存最大值为 100M，所以应该在申请快到100M的时候，发生堆外内存OOM；
看看执行情况：
可以看到，这里生成了100M对象，并且继续生成的时候，堆外内存区域不够了，然后是先去执行 System.gc()；
但是由于对象被引用持有没法被GC掉，所以就发生了 java.lang.OutOfMemoryError: Direct buffer memory；
4.2 模拟2
/**
*
* 直接内存溢出
*
* jvm options：
* -XX:MaxDirectMemorySize=100m -verbose:gc -XX:+PrintGCDetails
*/
*/
public class DirectByteBufferOomDemo {
public static void main(String[] args) {
int count = 0;
// List<ByteBuffer> list = new ArrayList<>();
while (true) {
ByteBuffer byteBuffer = ByteBuffer.allocateDirect(1 * 1024 * 1024);
// list.add(byteBuffer);
System.out.println("当前创建了 " + (++count) + "M 的对象");
}
}
}
跟模拟1不同是，注释掉list的代码，让申请的 DirectByteBuffer对象没有引用指向，也就是会成为垃圾对象；
在申请堆外内存不足时，DirectByteBuffer中手动调用 System.gc()的时候，会回收掉它们，所以这里不应该发生堆外内存OOM；
看看执行情况：
可以看到，每生成100M对象的时候，执行 System.gc()；
由于对象是垃圾对象可以被回收，在GC之后就又可以继续生成，所以并没有发生 java.lang.OutOfMemoryError: Direct buffer memory；
4.3 模拟3
/**
*
* 直接内存溢出
*
* jvm options：
* -XX:MaxDirectMemorySize=100m -verbose:gc -XX:+PrintGCDetails -XX:+DisableExplicitGC
*/
public class DirectByteBufferOomDemo {
public static void main(String[] args) {
int count = 0;
// List<ByteBuffer> list = new ArrayList<>();
while (true) {
ByteBuffer byteBuffer = ByteBuffer.allocateDirect(1 * 1024 * 1024);
// list.add(byteBuffer);
System.out.println("当前创建了 " + (++count) + "M 的对象");
}
}
}
跟模拟2不同的是，添加了jvm参数 -XX:+DisableExplicitGC，这个参数禁止代码中的显示 System.gc()操作；
所以在堆外内存满的时候，执行System.gc()无效，不能回收掉已经是垃圾对象了的DirectByteBuffer对象，也就不能释放掉堆外内存，应该会发生堆外内存OOM；
看看执行情况：
可以看到，在生成了100M对象的时候，发生了 java.lang.OutOfMemoryError: Direct buffer memory；
5. 堆外内存 OOM 的定位及解决
同样，遇到系统崩溃的时候，首先还是登陆服务器查看系统日志，这个时候会看到 java.lang.OutOfMemoryError: Direct buffer memory这样的报错，也就知道了这是堆外内存的OOM；
在发生堆外内存OOM的时候，即使你配置了dump开关，它也不会在系统发生崩溃时生成dump日志（这个很明显，堆外内存都没有在堆中，肯定不会给你生成堆栈的dump日志）；
但是这个报错的下方，会携带上 真正引发堆外内存OOM 的具体类和方法及里面的代码行数；
这样你就能知道，是你在代码中手动生成堆外内存导致的，还是一些框架（比如jetty、netty等都会）里面生成堆外内存导致的；
-
如果是你在代码手动生成堆外内存导致的，那你就需要去仔细检查你的代码是否有问题，是否生成了太多的 DirectByteBuffer并且不能被回收；
-
如果你的代码没有这种问题，或者是框架里面引发的问题，那就得从GC去考虑了：
-
首先查看是否配置了
-XX:+DisableExplicitGC这个限制；- 如果配置了就得放开这个限制，让 DirectByteBuffer中的System.gc()生效；
- 但是这个时候，就得注意你自己的代码中，尽量不要有 System.gc()的执行，否则可能会引发频繁的 FGC；
- 如果是配置了这个参数的话，那去掉这个配置基本就解决这个问题了；
-
如果不是，那就有点复杂了；需要使用我们前面介绍到的 jstat工具，去判断jvm内存区域大小分配是否有问题；
- 比如，上面提到的那种情况，DirectByteBuffer对象进入了老年代，迟迟不能被回收，就没法释放堆外内存空间，然后导致了堆外内存OOM；
- 当检查到是这类问题时，就需要调整jvm参数来合理分配各区域内存大小了；做到能够让DirectByteBuffer对象被及时回收释放堆外内存空间；
- 具体的查看jvm内存划分是否合理的方式就不再次在这里进行介绍了，可以参考前面的文章；