概述
廣義的堆外記憶體
說到堆外記憶體，那大家肯定想到堆内記憶體，這也是我們大家接觸最多的，我們在jvm參數裡通常設定-Xmx來指定我們的堆的最大值，不過這還不是我們了解的Java堆，-Xmx的值是新生代和老生代的和的最大值，我們在jvm參數裡通常還會加一個參數-XX:MaxPermSize來指定持久代的最大值，那麼我們認識的Java堆的最大值其實是-Xmx和-XX:MaxPermSize的總和，在分代算法下，新生代，老生代和持久代是連續的虛拟位址，因為它們是一起配置設定的，那麼剩下的都可以認為是堆外記憶體(廣義的)了，這些包括了jvm本身在運作過程中配置設定的記憶體，codecache，jni裡配置設定的記憶體，DirectByteBuffer配置設定的記憶體等等
狹義的堆外記憶體
而作為java開發者，我們常說的堆外記憶體溢出了，其實是狹義的堆外記憶體，這個主要是指java.nio.DirectByteBuffer在建立的時候配置設定記憶體，我們這篇文章裡也主要是講狹義的堆外記憶體，因為它和我們平時碰到的問題比較密切
JDK/JVM裡DirectByteBuffer的實作
DirectByteBuffer通常用在通信過程中做緩沖池，在mina，netty等nio架構中屢見不鮮，先來看看JDK裡的實作：
通過上面的構造函數我們知道，真正的記憶體配置設定是使用的Bits.reserveMemory方法
通過上面的代碼我們知道可以通過-XX:MaxDirectMemorySize來指定最大的堆外記憶體，那麼我們首先引入兩個問題
- 堆外記憶體預設是多大
- 為什麼要主動調用System.gc()
如果我們沒有通過-XX:MaxDirectMemorySize來指定最大的堆外記憶體，那麼預設的最大堆外記憶體是多少呢，我們還是通過代碼來分析
上面的代碼裡我們看到調用了sun.misc.VM.maxDirectMemory()
看到上面的代碼之後是不是誤以為預設的最大值是64M？其實不是的，說到這個值得從java.lang.System這個類的初始化說起
上面這個方法在jvm啟動的時候對System這個類做初始化的時候執行的，是以執行時間非常早，我們看到裡面調用了sun.misc.VM.saveAndRemoveProperties(props):
如果我們通過-Dsun.nio.MaxDirectMemorySize指定了這個屬性，隻要它不等于-1，那效果和加了-XX:MaxDirectMemorySize一樣的，如果兩個參數都沒指定，那麼最大堆外記憶體的值來自于directMemory = Runtime.getRuntime().maxMemory()，這是一個native方法
其中在我們使用CMS GC的情況下的實作如下，其實是新生代的最大值-一個survivor的大小+老生代的最大值，也就是我們設定的-Xmx的值裡除去一個survivor的大小就是預設的堆外記憶體的大小了
為什麼要主動調用System.gc
既然要調用System.gc，那肯定是想通過觸發一次gc操作來回收堆外記憶體，不過我想先說的是堆外記憶體不會對gc造成什麼影響(這裡的System.gc除外)，但是堆外記憶體的回收其實依賴于我們的gc機制，首先我們要知道在java層面和我們在堆外配置設定的這塊記憶體關聯的隻有與之關聯的DirectByteBuffer對象了，它記錄了這塊記憶體的基位址以及大小，那麼既然和gc也有關，那就是gc能通過操作DirectByteBuffer對象來間接操作對應的堆外記憶體了。DirectByteBuffer對象在建立的時候關聯了一個PhantomReference，說到PhantomReference它其實主要是用來跟蹤對象何時被回收的，它不能影響gc決策，但是gc過程中如果發現某個對象除了隻有PhantomReference引用它之外，并沒有其他的地方引用它了，那将會把這個引用放到java.lang.ref.Reference.pending隊列裡，在gc完畢的時候通知ReferenceHandler這個守護線程去執行一些後置處理，而DirectByteBuffer關聯的PhantomReference是PhantomReference的一個子類，在最終的處理裡會通過Unsafe的free接口來釋放DirectByteBuffer對應的堆外記憶體塊
JDK裡ReferenceHandler的實作：
可見如果pending為空的時候，會通過lock.wait()一直等在那裡，其中喚醒的動作是在jvm裡做的，當gc完成之後會調用如下的方法VM_GC_Operation::doit_epilogue()，在方法末尾會調用lock的notify操作，至于pending隊列什麼時候将引用放進去的，其實是在gc的引用處理邏輯中放進去的，針對引用的處理後面可以專門寫篇文章來介紹
對于System.gc的實作，之前寫了一篇文章來重點介紹，JVM源碼分析之SystemGC完全解讀，它會對新生代的老生代都會進行記憶體回收，這樣會比較徹底地回收DirectByteBuffer對象以及他們關聯的堆外記憶體，我們dump記憶體發現DirectByteBuffer對象本身其實是很小的，但是它後面可能關聯了一個非常大的堆外記憶體，是以我們通常稱之為『冰山對象』，我們做ygc的時候會将新生代裡的不可達的DirectByteBuffer對象及其堆外記憶體回收了，但是無法對old裡的DirectByteBuffer對象及其堆外記憶體進行回收，這也是我們通常碰到的最大的問題，如果有大量的DirectByteBuffer對象移到了old，但是又一直沒有做cms gc或者full gc，而隻進行ygc，那麼我們的實體記憶體可能被慢慢耗光，但是我們還不知道發生了什麼，因為heap明明剩餘的記憶體還很多(前提是我們禁用了System.gc)。
為什麼要使用堆外記憶體
DirectByteBuffer在建立的時候會通過Unsafe的native方法來直接使用malloc配置設定一塊記憶體，這塊記憶體是heap之外的，那麼自然也不會對gc造成什麼影響(System.gc除外)，因為gc耗時的操作主要是操作heap之内的對象，對這塊記憶體的操作也是直接通過Unsafe的native方法來操作的，相當于DirectByteBuffer僅僅是一個殼，還有我們通信過程中如果資料是在Heap裡的，最終也還是會copy一份到堆外，然後再進行發送，是以為什麼不直接使用堆外記憶體呢。對于需要頻繁操作的記憶體，并且僅僅是臨時存在一會的，都建議使用堆外記憶體，并且做成緩沖池，不斷循環利用這塊記憶體。
為什麼不能大面積使用堆外記憶體
如果我們大面積使用堆外記憶體并且沒有限制，那遲早會導緻記憶體溢出，畢竟程式是跑在一台資源受限的機器上，因為這塊記憶體的回收不是你直接能控制的，當然你可以通過别的一些途徑，比如反射，直接使用Unsafe接口等，但是這些務必給你帶來了一些煩惱，Java與生俱來的優勢被你完全抛棄了—開發不需要關注記憶體的回收，由gc算法自動去實作。另外上面的gc機制與堆外記憶體的關系也說了，如果一直觸發不了cms gc或者full gc，那麼後果可能很嚴重。
轉載自PerfMa社群