[[181296]]

概述

廣義的堆外內(nèi)存

說(shuō)到堆外內(nèi)存，那大家肯定想到堆內(nèi)內(nèi)存，這也是我們大家接觸最多的，我們?cè)趈vm參數(shù)里通常設(shè)置-Xmx來(lái)指定我們的堆的***值，不過(guò)這還不是我們理解的Java堆，-Xmx的值是新生代和老生代的和的***值，我們?cè)趈vm參數(shù)里通常還會(huì)加一個(gè)參數(shù)-XX:MaxPermSize來(lái)指定持久代的***值，那么我們認(rèn)識(shí)的Java堆的***值其實(shí)是-Xmx和-XX:MaxPermSize的總和，在分代算法下，新生代，老生代和持久代是連續(xù)的虛擬地址，因?yàn)樗鼈兪且黄鸱峙涞?，那么剩下的都可以認(rèn)為是堆外內(nèi)存(廣義的)了，這些包括了jvm本身在運(yùn)行過(guò)程中分配的內(nèi)存，codecache，jni里分配的內(nèi)存，DirectByteBuffer分配的內(nèi)存等等

狹義的堆外內(nèi)存

而作為java開發(fā)者，我們常說(shuō)的堆外內(nèi)存溢出了，其實(shí)是狹義的堆外內(nèi)存，這個(gè)主要是指java.nio.DirectByteBuffer在創(chuàng)建的時(shí)候分配內(nèi)存，我們這篇文章里也主要是講狹義的堆外內(nèi)存，因?yàn)樗臀覀兤綍r(shí)碰到的問(wèn)題比較密切

JDK/JVM里DirectByteBuffer的實(shí)現(xiàn)

DirectByteBuffer通常用在通信過(guò)程中做緩沖池，在mina，netty等nio框架中屢見(jiàn)不鮮，先來(lái)看看JDK里的實(shí)現(xiàn)：

通過(guò)上面的構(gòu)造函數(shù)我們知道，真正的內(nèi)存分配是使用的Bits.reserveMemory方法

通過(guò)上面的代碼我們知道可以通過(guò)-XX:MaxDirectMemorySize來(lái)指定***的堆外內(nèi)存，那么我們首先引入兩個(gè)問(wèn)題

堆外內(nèi)存默認(rèn)是多大

為什么要主動(dòng)調(diào)用System.gc()

• 堆外內(nèi)存默認(rèn)是多大
• 如果我們沒(méi)有通過(guò)-XX:MaxDirectMemorySize來(lái)指定***的堆外內(nèi)存，那么默認(rèn)的***堆外內(nèi)存是多少呢，我們還是通過(guò)代碼來(lái)分析

上面的代碼里我們看到調(diào)用了sun.misc.VM.maxDirectMemory()

看到上面的代碼之后是不是誤以為默認(rèn)的***值是64M?其實(shí)不是的，說(shuō)到這個(gè)值得從java.lang.System這個(gè)類的初始化說(shuō)起

上面這個(gè)方法在jvm啟動(dòng)的時(shí)候?qū)ystem這個(gè)類做初始化的時(shí)候執(zhí)行的，因此執(zhí)行時(shí)間非常早，我們看到里面調(diào)用了sun.misc.VM.saveAndRemoveProperties(props):

如果我們通過(guò)-Dsun.nio.MaxDirectMemorySize指定了這個(gè)屬性，只要它不等于-1，那效果和加了-XX:MaxDirectMemorySize一樣的，如果兩個(gè)參數(shù)都沒(méi)指定，那么***堆外內(nèi)存的值來(lái)自于directMemory = Runtime.getRuntime().maxMemory()，這是一個(gè)native方法

其中在我們使用CMS GC的情況下的實(shí)現(xiàn)如下，其實(shí)是新生代的***值-一個(gè)survivor的大小+老生代的***值，也就是我們?cè)O(shè)置的-Xmx的值里除去一個(gè)survivor的大小就是默認(rèn)的堆外內(nèi)存的大小了

為什么要主動(dòng)調(diào)用System.gc

既然要調(diào)用System.gc，那肯定是想通過(guò)觸發(fā)一次gc操作來(lái)回收堆外內(nèi)存，不過(guò)我想先說(shuō)的是堆外內(nèi)存不會(huì)對(duì)gc造成什么影響(這里的System.gc除外)，但是堆外內(nèi)存的回收其實(shí)依賴于我們的gc機(jī)制，首先我們要知道在java層面和我們?cè)诙淹夥峙涞倪@塊內(nèi)存關(guān)聯(lián)的只有與之關(guān)聯(lián)的DirectByteBuffer對(duì)象了，它記錄了這塊內(nèi)存的基地址以及大小，那么既然和gc也有關(guān)，那就是gc能通過(guò)操作DirectByteBuffer對(duì)象來(lái)間接操作對(duì)應(yīng)的堆外內(nèi)存了。DirectByteBuffer對(duì)象在創(chuàng)建的時(shí)候關(guān)聯(lián)了一個(gè)PhantomReference，說(shuō)到PhantomReference它其實(shí)主要是用來(lái)跟蹤對(duì)象何時(shí)被回收的，它不能影響gc決策，但是gc過(guò)程中如果發(fā)現(xiàn)某個(gè)對(duì)象除了只有PhantomReference引用它之外，并沒(méi)有其他的地方引用它了，那將會(huì)把這個(gè)引用放到j(luò)ava.lang.ref.Reference.pending隊(duì)列里，在gc完畢的時(shí)候通知ReferenceHandler這個(gè)守護(hù)線程去執(zhí)行一些后置處理，而DirectByteBuffer關(guān)聯(lián)的PhantomReference是PhantomReference的一個(gè)子類，在最終的處理里會(huì)通過(guò)Unsafe的free接口來(lái)釋放DirectByteBuffer對(duì)應(yīng)的堆外內(nèi)存塊

JDK里ReferenceHandler的實(shí)現(xiàn)：

可見(jiàn)如果pending為空的時(shí)候，會(huì)通過(guò)lock.wait()一直等在那里，其中喚醒的動(dòng)作是在jvm里做的，當(dāng)gc完成之后會(huì)調(diào)用如下的方法VM_GC_Operation::doit_epilogue()，在方法末尾會(huì)調(diào)用lock的notify操作，至于pending隊(duì)列什么時(shí)候?qū)⒁梅胚M(jìn)去的，其實(shí)是在gc的引用處理邏輯中放進(jìn)去的，針對(duì)引用的處理后面可以專門寫篇文章來(lái)介紹

對(duì)于System.gc的實(shí)現(xiàn)，之前寫了一篇文章來(lái)重點(diǎn)介紹，JVM源碼分析之SystemGC完全解讀，它會(huì)對(duì)新生代的老生代都會(huì)進(jìn)行內(nèi)存回收，這樣會(huì)比較徹底地回收DirectByteBuffer對(duì)象以及他們關(guān)聯(lián)的堆外內(nèi)存，我們dump內(nèi)存發(fā)現(xiàn)DirectByteBuffer對(duì)象本身其實(shí)是很小的，但是它后面可能關(guān)聯(lián)了一個(gè)非常大的堆外內(nèi)存，因此我們通常稱之為『冰山對(duì)象』，我們做ygc的時(shí)候會(huì)將新生代里的不可達(dá)的DirectByteBuffer對(duì)象及其堆外內(nèi)存回收了，但是無(wú)法對(duì)old里的DirectByteBuffer對(duì)象及其堆外內(nèi)存進(jìn)行回收，這也是我們通常碰到的***的問(wèn)題，如果有大量的DirectByteBuffer對(duì)象移到了old，但是又一直沒(méi)有做cms gc或者full gc，而只進(jìn)行ygc，那么我們的物理內(nèi)存可能被慢慢耗光，但是我們還不知道發(fā)生了什么，因?yàn)閔eap明明剩余的內(nèi)存還很多(前提是我們禁用了System.gc)。

為什么要使用堆外內(nèi)存

DirectByteBuffer在創(chuàng)建的時(shí)候會(huì)通過(guò)Unsafe的native方法來(lái)直接使用malloc分配一塊內(nèi)存，這塊內(nèi)存是heap之外的，那么自然也不會(huì)對(duì)gc造成什么影響(System.gc除外)，因?yàn)間c耗時(shí)的操作主要是操作heap之內(nèi)的對(duì)象，對(duì)這塊內(nèi)存的操作也是直接通過(guò)Unsafe的native方法來(lái)操作的，相當(dāng)于DirectByteBuffer僅僅是一個(gè)殼，還有我們通信過(guò)程中如果數(shù)據(jù)是在Heap里的，最終也還是會(huì)copy一份到堆外，然后再進(jìn)行發(fā)送，所以為什么不直接使用堆外內(nèi)存呢。對(duì)于需要頻繁操作的內(nèi)存，并且僅僅是臨時(shí)存在一會(huì)的，都建議使用堆外內(nèi)存，并且做成緩沖池，不斷循環(huán)利用這塊內(nèi)存。

為什么不能大面積使用堆外內(nèi)存

如果我們大面積使用堆外內(nèi)存并且沒(méi)有限制，那遲早會(huì)導(dǎo)致內(nèi)存溢出，畢竟程序是跑在一臺(tái)資源受限的機(jī)器上，因?yàn)檫@塊內(nèi)存的回收不是你直接能控制的，當(dāng)然你可以通過(guò)別的一些途徑，比如反射，直接使用Unsafe接口等，但是這些務(wù)必給你帶來(lái)了一些煩惱，Java與生俱來(lái)的優(yōu)勢(shì)被你完全拋棄了—開發(fā)不需要關(guān)注內(nèi)存的回收，由gc算法自動(dòng)去實(shí)現(xiàn)。另外上面的gc機(jī)制與堆外內(nèi)存的關(guān)系也說(shuō)了，如果一直觸發(fā)不了cms gc或者full gc，那么后果可能很嚴(yán)重。

【本文是51CTO專欄作者李嘉鵬的原創(chuàng)文章，轉(zhuǎn)載請(qǐng)通過(guò)微信公眾號(hào)（你假笨，id:lovestblog）聯(lián)系作者本人獲取授權(quán)】

戳這里，看該作者更多好文