JVM源碼分析之堆外內存徹底解讀

概述

廣義的堆外內存

說到堆外內存，那你們確定想到堆內內存，這也是咱們你們接觸最多的，咱們在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，那麼後果可能很嚴重。

推薦閱讀

JVM菜鳥進階高手之路十一（eden survivor分配問題）

Javassist實現JDK動態代理