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内存划分是否合理的方式就不再次在这里进行介绍了,可以参考前面的文章;