1. 引言
很久沒有遇到堆外內存相關的問題了，五一假期剛結束，便不期而遇，以前也處理過幾次這類問題，但都沒有總結，覺得是時候總結一下了。
先來看一個 Demo：在 Demo 中分配堆外內存用的是 allocateDirect 方法，但其內部調用的是 DirectByteBuffer，換言之，DirectByteBuffer 才是實際操作堆外內存的類，因此，本場 Chat 將圍繞 DirectByteBuffer 展開。
importjava.nio.ByteBuffer;publicclassDemo{publicstaticvoidmain(String[]args)
{//分配一塊1024Bytes的堆外內存(直接內存)
//allocateDirect方法內部調用的是DirectByteBuffer
ByteBufferbuffer=ByteBuffer.allocateDirect(1024);
System.out.println(buffer.capacity);//向堆外內存中讀寫數據
buffer.putInt(0,2018);
System.out.println(buffer.getInt(0));
}
}
2. 什麼是堆外內存？
Java 開發者一般都知道堆內存，但卻未必瞭解堆外內存。事實上，除了堆內存，Java 還可以使用堆外內存，也稱直接內存（Direct Memory）。
顧名思義，堆外內存是在 JVM Heap 之外分配的內存塊，並不是 JVM 規範中定義的內存區域，堆外內存用得並不多，但十分重要。
讀者也許會有一個疑問：既然已經有堆內存，為什麼還要用堆外內存呢？這主要是因為堆外內存在 IO 操作方面的優勢。
舉一個例子：在通信中，將存在於堆內存中的數據 flush 到遠程時，需要首先將堆內存中的數據拷貝到堆外內存中，然後再寫入 Socket 中；
如果直接將數據存到堆外內存中就可以避免上述拷貝操作，提升性能。類似的例子還有讀寫文件。
目前，很多 NIO 框架 （如 netty，rpc） 會採用 Java 的 DirectByteBuffer 類來操作堆外內存，DirectByteBuffer 類對象本身位於 Java 內存模型的堆中，由 JVM 直接管控、操縱。
但是，DirectByteBuffer 中用於分配堆外內存的方法 unsafe.allocateMemory(size) 是個一個 native 方法，本質上是用 C 的 malloc 來進行分配的。
分配的內存是系統本地的內存，並不在 Java 的內存中，也不屬於 JVM 管控範圍，所以在 DirectByteBuffer 一定會存在某種特別的方式來操縱堆外內存。
3. 堆外內存創建過程深度解析
首先，我們來看一下 DirectByteBuffer 源代碼，從中洞悉分配堆外內存的過程：
3.1 第一個重要方法：
Bits.reserveMemory(size,cap);
源代碼如下：
該方法用於在系統中保存總分配內存（按頁分配）的大小和實際內存的大小，具體執行中需要首先用 tryReserveMemory 方法來判斷系統內存（堆外內存）是否足夠，具體代碼如下：
從 Bits.reserveMemory(size, cap) 源碼可以看出，其執行過程中，可能遇到以下三種情況：
1. 最樂觀的情況：可用堆外內存足夠，reserveMemory 方法返回 true，該方法結束。
2. 如果不幸，堆外內存不足，則須進行第二步：
jlra.tryHandlePendingReference
會觸發一次非堵塞的
Reference#tryHandlePending(false)，該方法會將已經被 JVM 垃圾回收的 DirectBuffer 對象的堆外內存釋放。
3. 如果在進行一次堆外內存資源回收後，還不夠進行本次堆外內存分配的話，則進行 GC 操作：
System.gc 會觸發一個 Full GC，當然，前提是你沒有顯示的設置 - XX:+DisableExplicitGC 來禁用顯式 GC。同時，需要注意的是，調用 System.gc 並不能夠保證 Full GC 馬上就能被執行。
調用 System.gc 後，接下來會最多進行 9 次循環嘗試，仍然通過 tryReserveMemory 方法來判斷是否有足夠的堆外內存可供分配操作。每次嘗試都會 sleep，以便 Full GC 能夠完成，如下代碼所示。
4. 最不幸的情況，經過 9 次循環嘗試後，如果仍然沒有足夠的堆外內存，將拋出 OutOfMemoryError 異常。
綜上所述，Bits.reserveMemory(size, cap) 方法將依次執行以下操作：
1.如果可用堆外內存足以分配給當前要創建的堆外內存大小時，直接返回 True；
2.如果堆外內存不足，則觸發一次非堵塞的 Reference#tryHandlePending(false)。該方法會將已經被 JVM 垃圾回收的 DirectBuffer 對象的堆外內存釋放；
3.如果進行一次堆外內存資源回收後，還不夠進行本次堆外內存分配的話，則進行 System.gc。
System.gc 會觸發一個 Full GC，需要注意的是，調用 System.gc 並不能夠保證 Full GC 馬上就能被執行。
所以在後面打代碼中，會進行最多 9 次嘗試，看是否有足夠的可用堆外內存來分配堆外內存。
並且每次嘗試之前，都對延遲等待時間，已給 JVM 足夠的時間去完成 Full GC 操作。
4.如果 9 次嘗試後依舊沒有足夠的可用堆外內存來分配本次堆外內存，則拋出 OutOfMemoryError(“Direct buffer memory”) 異常。
3.2 第二個重要方法：
unsafe.allocateMemory(size)
......
3.3 第三個重要方法：
Cleaner.create(this, new Deallocator(base, size, cap))
......
閱讀更多 中國存儲 的文章
