Direct Memory堆外内存（转载）

JVM可以使用的内存分外2种：堆内存和堆外内存.

    堆内存完全由JVM负责分配和释放，如果程序没有缺陷代码导致内存泄露，那么就不会遇到java.lang.OutOfMemoryError这个错误。

    使用堆外内存，就是为了能直接分配和释放内存，提高效率。JDK5.0之后，代码中能直接操作本地内存的方式有2种：使用未公开的Unsafe和NIO包下ByteBuffer。

作为JAVA开发者我们经常用java.nio.DirectByteBuffer对象进行堆外内存的管理和使用，它会在对象创建的时候就分配堆外内存。

DirectByteBuffer类是在Java Heap外分配内存，对堆外内存的申请主要是通过成员变量unsafe来操作

Direct Memory的回收机制：
Direct Memory是受GC控制的，例如ByteBuffer bb = ByteBuffer.allocateDirect(1024)，这段代码的执行会在堆外占用1k的内存，Java堆内只会占用一个对象的指针引用的大小，堆外的这1k的空间只有当bb对象被回收时，才会被回收，这里会发现一个明显的不对称现象，就是堆外可能占用了很多，而堆内没占用多少，导致还没触发GC，那就很容易出现Direct Memory造成物理内存耗光。

JDK中使用DirectByteBuffer对象来表示堆外内存，每个DirectByteBuffer对象在初始化时，都会创建一个对应的Cleaner对象，用于保存堆外内存的元信息（开始地址、大小和容量等），当DirectByteBuffer被GC回收后，Cleaner对象被放入ReferenceQueue中，然后由ReferenceHandler守护线程调用unsafe.freeMemory(address)，回收堆外内存。 ( 在Cleaner 内部中通过一个列表，维护了一个针对每一个 directBuffer 的一个回收堆外内存的 线程对象(Runnable)，回收操作是发生在 Cleaner 的 clean() 方法中。)

Direct ByteBuffer分配出去的内存其实也是由GC负责回收的，而不像Unsafe是完全自行管理的，Hotspot在GC时会扫描Direct ByteBuffer对象是否有引用，如没有则同时也会回收其占用的堆外内存。

主动回收： 对于Sun的JDK，只要从DirectByteBuffer里取出那个sun.misc.Cleaner，然后调用它的clean()就行； 
基于 GC 回收：堆内的DirectByteBuffer对象被GC时，会调用cleaner回收其引用的堆外内存。问题是YGC只会将将新生代里的不可达的DirectByteBuffer对象及其堆外内存回收，如果有大量的DirectByteBuffer对象移到了old区，但是又一直没有做CMS GC或者FGC，而只进行YGC，物理内存会被慢慢耗光，触发OutOfMemoryError  (水平有限, 这句话还没懂) 因此为了避免这种悲剧的发生，通过-XX:MaxDirectMemorySize来指定最大的堆外内存大小，当使用达到了阈值的时候将调用System.gc来做一次full gc，以此来回收掉没有被使用的堆外内存。

详细些的回收机制参考下连接:

https://www.jianshu.com/p/35cf0f348275

堆外内存的好处：
可以扩展至更大的内存空间。比如超过1TB甚至比主存还大的空间
理论上能减少GC暂停时间（节约了大量的堆内内存）
可以在进程间共享，减少JVM间的对象复制，使得JVM的分割部署更容易实现
它的持久化存储可以支持快速重启，同时还能够在测试环境中重现生产数据
堆外内存能够提升IO效率
堆内内存由JVM管理，属于“用户态”；而堆外内存由OS管理，属于“内核态”。
如果从堆内向磁盘写数据时，数据会被先复制到堆外内存，即内核缓冲区，然后再由OS写入磁盘，使用堆外内存避免了数据从用户内向内核态的拷贝。