## 什么是堆外内存 ### 堆内内存（on-heap memory）回顾 堆外内存和堆内内存是相对的两个概念，其中堆内内存是我们平常工作中接触比较多的，我们在jvm参数中只要使用-Xms，-Xmx等参数就可以设置堆的大小和最大值，理解jvm的堆还需要知道下面这个公式： ``` 堆内内存 = 新生代+老年代+持久代 ``` 如下面的图所示：  在使用堆内内存（on-heap memory）的时候，完全遵守JVM虚拟机的内存管理机制，采用垃圾回收器（GC）统一进行内存管理，GC会在某些特定的时间点进行一次彻底回收，也就是Full GC，GC会对所有分配的堆内内存进行扫描，在这个过程中会对JAVA应用程序的性能造成一定影响，还可能会产生Stop The World。 常见的垃圾回收算法主要有： * 引用计数器法（Reference Counting） * 标记清除法（Mark-Sweep） * 复制算法（Coping） * 标记压缩法（Mark-Compact） * 分代算法（Generational Collecting） * 分区算法（Region） ### 堆外内存（off-heap memory）介绍 又叫做直接内存。 和堆内内存相对应，堆外内存就是把内存对象分配在Java虚拟机的堆以外的内存，这些内存直接受操作系统管理（而不是虚拟机），这样做的结果就是能够在一定程度上减少垃圾回收对应用程序造成的影响。 作为JAVA开发者我们经常用java.nio.DirectByteBuffer对象进行堆外内存的管理和使用，它会在对象创建的时候就分配堆外内存。 DirectByteBuffer类是在Java Heap外分配内存，对堆外内存的申请主要是通过成员变量unsafe来操作，下面介绍构造方法。 ``` 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类保存总分配内存(按页分配)的大小和实际内存的大小 Bits.reserveMemory(size, cap); long base = 0; try { //在堆外内存的基地址，指定内存大小 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; } cleaner = Cleaner.create(this, new Deallocator(base, size, cap)); att = null; } ``` 注：在Cleaner 内部中通过一个列表，维护了一个针对每一个 directBuffer 的一个回收堆外内存的 线程对象(Runnable)，回收操作是发生在 Cleaner 的 clean() 方法中。 ``` 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); } } ``` ## 概念和特征 * 直接内存并非 JVMS 定义的标准 Java 运行时内存。 * JDK1.4 加入了新的 NIO 机制，目的是防止 Java 堆 和 Native 堆之间往复的数据复制带来的性能损耗，此后 NIO 可以使用 Native 的方式直接在 Native 堆分配内存。 * 直接内存区域是全局共享的内存区域。 * 直接内存区域可以进行自动内存管理(GC)，但机制并不完善。 * 本机的 Native 堆(直接内存) 不受 JVM 堆内存大小限制。 * 可能出现 OutOfMemoryError 异常。 * ## 使用堆外内存的优点 * 减少了垃圾回收 因为垃圾回收会暂停其他的工作。 * 加快了复制的速度 堆内在flush到远程时，会先复制到直接内存（非堆内存），然后在发送；而堆外内存相当于省略掉了这个工作。 ## 使用DirectByteBuffer的注意事项 同样任何一个事物使用起来有优点就会有缺点，堆外内存的缺点就是内存难以控制，使用了堆外内存就间接失去了JVM管理内存的可行性，改由自己来管理，当发生内存溢出时排查起来非常困难。 java.nio.DirectByteBuffer对象在创建过程中会先通过Unsafe接口直接通过os::malloc来分配内存，然后将内存的起始地址和大小存到java.nio.DirectByteBuffer对象里，这样就可以直接操作这些内存。这些内存只有在DirectByteBuffer回收掉之后才有机会被回收，因此如果这些对象大部分都移到了old，但是一直没有触发CMS GC或者Full GC，那么悲剧将会发生，因为你的物理内存被他们耗尽了，因此为了避免这种悲剧的发生，通过-XX:MaxDirectMemorySize来指定最大的堆外内存大小，当使用达到了阈值的时候将调用System.gc来做一次full gc，以此来回收掉没有被使用的堆外内存。 ## DirectByteBuffer使用测试 我们在写NIO程序经常使用ByteBuffer来读取或者写入数据，那么使用ByteBuffer.allocate(capability)还是使用ByteBuffer.allocteDirect(capability)来分配缓存了？第一种方式是分配JVM堆内存，属于GC管辖范围，由于需要拷贝所以速度相对较慢；第二种方式是分配OS本地内存，不属于GC管辖范围，由于不需要内存拷贝所以速度相对较快。 代码如下： ``` import java.nio.ByteBuffer; import java.util.concurrent.TimeUnit; public class DirectByteBufferTest { public static void main(String[] args) throws InterruptedException{ //分配128MB直接内存 ByteBuffer bb = ByteBuffer.allocateDirect(1024*1024*128); TimeUnit.SECONDS.sleep(10); System.out.println("ok"); } } ``` ### 测试用例1 设置JVM参数-Xmx100m，运行异常，因为如果没设置-XX:MaxDirectMemorySize，则默认与-Xmx参数值相同，分配128M直接内存超出限制范围。 ``` Exception in thread "main" java.lang.OutOfMemoryError: Direct buffer memory at java.nio.Bits.reserveMemory(Bits.java:658) at java.nio.DirectByteBuffer.<init>(DirectByteBuffer.java:123) at java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:306) at com.stevex.app.nio.DirectByteBufferTest.main(DirectByteBufferTest.java:8) ``` ### 测试用例2 设置JVM参数-Xmx256m，运行正常，因为128M小于256M，属于范围内分配。 ### 测试用例3 设置JVM参数-Xmx256m -XX:MaxDirectMemorySize=100M，运行异常，分配的直接内存128M超过限定的100M。 ``` Exception in thread "main" java.lang.OutOfMemoryError: Direct buffer memory at java.nio.Bits.reserveMemory(Bits.java:658) at java.nio.DirectByteBuffer.<init>(DirectByteBuffer.java:123) at java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:306) at com.stevex.app.nio.DirectByteBufferTest.main(DirectByteBufferTest.java:8) ``` ### 测试用例4 设置JVM参数-Xmx768m，运行程序观察内存使用变化，会发现clean()后内存马上下降，说明使用clean()方法能有效及时回收直接缓存。 代码如下： ``` import java.nio.ByteBuffer; import java.util.concurrent.TimeUnit; import sun.nio.ch.DirectBuffer; public class DirectByteBufferTest { public static void main(String[] args) throws InterruptedException{ //分配512MB直接缓存 ByteBuffer bb = ByteBuffer.allocateDirect(1024*1024*512); TimeUnit.SECONDS.sleep(10); //清除直接缓存 ((DirectBuffer)bb).cleaner().clean(); TimeUnit.SECONDS.sleep(10); System.out.println("ok"); } } ``` ### 异常演示 测试代码： ``` public class TestNativeHeap { /** * VM Args: -XX:MaxDirectMemorySize=10M */ // 每次内存分配大小 private static int _1M =1024*1024; public static void main(String[] args) throws IllegalArgumentException, IllegalAccessException { Field unsafeFiled = Unsafe.class.getFields()[0]; unsafeFiled.setAccessible(true); Unsafe unsafe = (Unsafe) unsafeFiled.get(null); while (true) { unsafe.allocateMemory(_1M); } } } ``` 以上代码运行会出现 OutOfMemoryError 异常，原因是不断申请内存将超出 Native 堆限制。 直接内存导致的 OutOfMemoryError 异常，在异常信息中不会有明显的堆栈区错误提示；同时另一大特点就是内存转储文件(dump)出来会非常小，如果项目中出现这种情况，并且直接或者间接地使用了 NIO 技术，那么应该考虑是否为直接内存导致的内存溢出。 ## 细说System.gc方法 ### JDK里的System.gc的实现 ``` /** * Runs the garbage collector. * <p> * Calling the <code>gc</code> method suggests that the Java Virtual * Machine expend effort toward recycling unused objects in order to * make the memory they currently occupy available for quick reuse. * When control returns from the method call, the Java Virtual * Machine has made a best effort to reclaim space from all discarded * objects. * <p> * The call <code>System.gc()</code> is effectively equivalent to the * call: * <blockquote><pre> * Runtime.getRuntime().gc() * </pre></blockquote> * * @see java.lang.Runtime#gc() */ public static void gc() { Runtime.getRuntime().gc(); } ``` 其实发现System.gc方法其实是调用的Runtime.getRuntime.gc()，我们再接着看。 ``` /* 运行垃圾收集器。 调用此方法表明，java虚拟机扩展 努力回收未使用的对象，以便内存可以快速复用， 当控制从方法调用返回的时候，虚拟机尽力回收被丢弃的对象 */ public native void gc(); ``` 这里看到gc方法是native的，在java层面只能到此结束了，代码只有这么多，要了解更多，可以看方法上面的注释，不过我们需要更深层次地来了解其实现，那还是准备好进入到jvm里去看看。 ### System.gc的作用有哪些 说起堆外内存免不了要提及System.gc方法，下面就是使用了System.gc的作用是什么？ * 做一次full gc * 执行后会暂停整个进程。 * System.gc我们可以禁掉，使用-XX:+DisableExplicitGC， * 其实一般在cms gc下我们通过-XX:+ExplicitGCInvokesConcurrent也可以做稍微高效一点的gc，也就是并行gc。 * 最常见的场景是RMI/NIO下的堆外内存分配等 注： 如果我们使用了堆外内存，并且用了DisableExplicitGC设置为true，那么就是禁止使用System.gc，这样堆外内存将无从触发极有可能造成内存溢出错误，在这种情况下可以考虑使用ExplicitGCInvokesConcurrent参数。 说起Full gc我们最先想到的就是stop thd world，这里要先提到VMThread，在jvm里有这么一个线程不断轮询它的队列，这个队列里主要是存一些VM_operation的动作，比如最常见的就是内存分配失败要求做GC操作的请求等，在对gc这些操作执行的时候会先将其他业务线程都进入到安全点，也就是这些线程从此不再执行任何字节码指令，只有当出了安全点的时候才让他们继续执行原来的指令，因此这其实就是我们说的stop the world(STW)，整个进程相当于静止了。 ## 开源堆外缓存框架 关于堆外缓存的开源实现。查询了一些资料后了解到的主要有： * Ehcache 3.0：3.0基于其商业公司一个非开源的堆外组件的实现。 * Chronical Map：OpenHFT包括很多类库，使用这些类库很少产生垃圾，并且应用程序使用这些类库后也很少发生Minor GC。类库主要包括：Chronicle Map，Chronicle Queue等等。 * OHC：来源于Cassandra 3.0， Apache v2。 * Ignite: 一个规模宏大的内存计算框架，属于Apache项目。