1. 引言

很久沒有遇到堆外內(nèi)存相關(guān)的問題了，五一假期剛結(jié)束，便不期而遇，以前也處理過幾次這類問題，但都沒有總結(jié)，覺得是時候總結(jié)一下了。

先來看一個 Demo：在 Demo 中分配堆外內(nèi)存用的是 allocateDirect 方法，但其內(nèi)部調(diào)用的是 DirectByteBuffer，換言之，DirectByteBuffer 才是實際操作堆外內(nèi)存的類，因此，本場 Chat 將圍繞 DirectByteBuffer 展開。

import?java.nio.ByteBuffer;public?class?Demo?{????public?static?void?main(?String[]?args?)?

{????????//分配一塊1024Bytes的堆外內(nèi)存(直接內(nèi)存)?

//allocateDirect方法內(nèi)部調(diào)用的是DirectByteBuffer?

ByteBuffer?buffer=ByteBuffer.allocateDirect(1024);?

System.out.println(buffer.capacity());????????//向堆外內(nèi)存中讀寫數(shù)據(jù)?

buffer.putInt(0,2018);?

System.out.println(buffer.getInt(0));????????

}?

}?

2. 什么是堆外內(nèi)存？

Java 開發(fā)者一般都知道堆內(nèi)存，但卻未必了解堆外內(nèi)存。事實上，除了堆內(nèi)存，Java 還可以使用堆外內(nèi)存，也稱直接內(nèi)存（Direct Memory）。

顧名思義，堆外內(nèi)存是在 JVM Heap 之外分配的內(nèi)存塊，并不是 JVM 規(guī)范中定義的內(nèi)存區(qū)域，堆外內(nèi)存用得并不多，但十分重要。

讀者也許會有一個疑問：既然已經(jīng)有堆內(nèi)存，為什么還要用堆外內(nèi)存呢？這主要是因為堆外內(nèi)存在 IO 操作方面的優(yōu)勢。

舉一個例子：在通信中，將存在于堆內(nèi)存中的數(shù)據(jù) flush 到遠程時，需要首先將堆內(nèi)存中的數(shù)據(jù)拷貝到堆外內(nèi)存中，然后再寫入 Socket 中；

如果直接將數(shù)據(jù)存到堆外內(nèi)存中就可以避免上述拷貝操作，提升性能。類似的例子還有讀寫文件。

目前，很多 NIO 框架 （如 netty，rpc） 會采用 Java 的 DirectByteBuffer 類來操作堆外內(nèi)存，DirectByteBuffer 類對象本身位于 Java 內(nèi)存模型的堆中，由 JVM 直接管控、操縱。

但是，DirectByteBuffer 中用于分配堆外內(nèi)存的方法 unsafe.allocateMemory(size) 是個一個 native 方法，本質(zhì)上是用 C 的 malloc 來進行分配的。

分配的內(nèi)存是系統(tǒng)本地的內(nèi)存，并不在 Java 的內(nèi)存中，也不屬于 JVM 管控范圍，所以在 DirectByteBuffer 一定會存在某種特別的方式來操縱堆外內(nèi)存。

3. 堆外內(nèi)存創(chuàng)建過程深度解析

首先，我們來看一下 DirectByteBuffer 源代碼，從中洞悉分配堆外內(nèi)存的過程：

3.1 第一個重要方法：

?

Bits.reserveMemory(size,?cap);?

源代碼如下：

該方法用于在系統(tǒng)中保存總分配內(nèi)存（按頁分配）的大小和實際內(nèi)存的大小，具體執(zhí)行中需要首先用 tryReserveMemory 方法來判斷系統(tǒng)內(nèi)存（堆外內(nèi)存）是否足夠，具體代碼如下：

從 Bits.reserveMemory(size, cap) 源碼可以看出，其執(zhí)行過程中，可能遇到以下三種情況：

1. 最樂觀的情況：可用堆外內(nèi)存足夠，reserveMemory 方法返回 true，該方法結(jié)束。

2. 如果不幸，堆外內(nèi)存不足，則須進行第二步：

?

jlra.tryHandlePendingReference()?

會觸發(fā)一次非堵塞的

Reference#tryHandlePending(false)，該方法會將已經(jīng)被 JVM 垃圾回收的 DirectBuffer 對象的堆外內(nèi)存釋放。

3. 如果在進行一次堆外內(nèi)存資源回收后，還不夠進行本次堆外內(nèi)存分配的話，則進行 GC 操作：

System.gc() 會觸發(fā)一個 Full GC，當然，前提是你沒有顯示的設(shè)置 - XX:+DisableExplicitGC 來禁用顯式 GC。同時，需要注意的是，調(diào)用 System.gc() 并不能夠保證 Full GC 馬上就能被執(zhí)行。

調(diào)用 System.gc() 后，接下來會最多進行 9 次循環(huán)嘗試，仍然通過 tryReserveMemory 方法來判斷是否有足夠的堆外內(nèi)存可供分配操作。每次嘗試都會 sleep，以便 Full GC 能夠完成，如下代碼所示。

4. 最不幸的情況，經(jīng)過 9 次循環(huán)嘗試后，如果仍然沒有足夠的堆外內(nèi)存，將拋出 OutOfMemoryError 異常。

綜上所述，Bits.reserveMemory(size, cap) 方法將依次執(zhí)行以下操作：

1.如果可用堆外內(nèi)存足以分配給當前要創(chuàng)建的堆外內(nèi)存大小時，直接返回 True；

2.如果堆外內(nèi)存不足，則觸發(fā)一次非堵塞的 Reference#tryHandlePending(false)。該方法會將已經(jīng)被 JVM 垃圾回收的 DirectBuffer 對象的堆外內(nèi)存釋放；

3.如果進行一次堆外內(nèi)存資源回收后，還不夠進行本次堆外內(nèi)存分配的話，則進行 System.gc()。

System.gc() 會觸發(fā)一個 Full GC，需要注意的是，調(diào)用 System.gc() 并不能夠保證 Full GC 馬上就能被執(zhí)行。

所以在后面打代碼中，會進行最多 9 次嘗試，看是否有足夠的可用堆外內(nèi)存來分配堆外內(nèi)存。

并且每次嘗試之前，都對延遲等待時間，已給 JVM 足夠的時間去完成 Full GC 操作。

4.如果 9 次嘗試后依舊沒有足夠的可用堆外內(nèi)存來分配本次堆外內(nèi)存，則拋出 OutOfMemoryError(“Direct buffer memory”) 異常。

3.2 第二個重要方法：

unsafe.allocateMemory(size)

......

3.3 第三個重要方法：

Cleaner.create(this, new Deallocator(base, size, cap))