對于我們程序員來講，F(xiàn)ullGC是我們既陌生又熟悉的老伙伴，如果它發(fā)生的不頻繁的話我們是不需要處理，如果它發(fā)生的很頻繁我們就需要及時的處理，不然會影響線上用戶的正常功能使用。下面我們一些常見的容易觸發(fā)FullGC場景。

1、實(shí)際業(yè)務(wù)中FullGC的場景分析

每當(dāng)服務(wù)器接受到請求之后，服務(wù)器需要構(gòu)造的各種各樣的不同的業(yè)務(wù)對象，與此同時，在實(shí)際的業(yè)務(wù)開發(fā)中，我們創(chuàng)建的業(yè)務(wù)對象很可能是一個大對象（如果對象是個大對象，那么對象就在老年代中存儲），如下圖所示：

圖片

如果此時我們創(chuàng)建好業(yè)務(wù)對象之后，還需要去調(diào)用其他的服務(wù)獲取業(yè)務(wù)，假設(shè)這個時候調(diào)用的其他服務(wù)超時了（服務(wù)C超時），如下圖所示：

圖片

那么一旦發(fā)生這種情況，那么此時我們創(chuàng)建的業(yè)務(wù)對象就會常駐在我們JVM內(nèi)存里面，如果我們的超時時間是15秒，那么在這個15秒里面我們這個系統(tǒng)里面的業(yè)務(wù)對象在內(nèi)存里面一直常駐。如果在高并發(fā)下出現(xiàn)這樣的情況，那么將會有很多的業(yè)務(wù)對象常駐在內(nèi)存中，如下圖所示：

圖片

此時在JVM中的就會出現(xiàn)年輕代的對象不斷的轉(zhuǎn)移到老年代中，如下圖所示：

圖片

由于老年代的中不斷又對象添加，最終會導(dǎo)致老年代中由于內(nèi)存不足，無法在開辟空間存在其他的業(yè)務(wù)對象，進(jìn)而觸發(fā)FullGC。

2、整理常見的發(fā)生FullGC的原因

FullGC是對老年代和新生代同時進(jìn)行回收，通常還會伴隨對元空間(或永久代)的回收，會導(dǎo)致機(jī)器停頓，影響線上服務(wù)。

（1）老年代空間不足

當(dāng)對象需要被分配到老年代，但老年代剩余空間無法滿足需求時，就會觸發(fā)FullGC。長期存活的對象進(jìn)入老年代，導(dǎo)致老年代的空間不足。

JVM給每個對象定義了一個年齡計數(shù)器（在對象頭中記錄）。對象在Eden區(qū)誕生，經(jīng)過一次YoungGC后存活，就會被移動到Survivor 區(qū)，并且年齡加1。當(dāng)它的年齡增長到一定程度(默認(rèn)為15，也可以通過參數(shù)設(shè)置)，下一次Young GC時它就會被晉升到老年代。如果此時老年代空間不足，就會觸發(fā)Full GC。

（2）空間分配擔(dān)保失敗

當(dāng)要準(zhǔn)備觸發(fā)一次YoungGC時，會進(jìn)行空間分配擔(dān)保，在擔(dān)保中，假如虛擬機(jī)檢查出老年代最大可用連續(xù)空間小于新生代所有對象的總空間，但是HandlePromotinotallow=false，那么就會進(jìn)行一次FullGC（HandlePromotionFailure這個配置在jdk7中不支持了，這一步驟在jdk7以后版本已取消）。

當(dāng)要準(zhǔn)備觸發(fā)一次YoungGC時，會進(jìn)行空間分配擔(dān)保，再擔(dān)保過程中，發(fā)現(xiàn)虛擬機(jī)會檢查老年代最大可用的連續(xù)空間小于新生代所有對象的總空間，但是HandlePromotinotallow=true，繼續(xù)檢查發(fā)現(xiàn)老年代最大可用連續(xù)空間小于歷次晉升到老年代的對象平均大小時，會觸發(fā)一次FullGC。

（3）調(diào)用 System.gc()方法

在代碼中直接調(diào)用System.gc()或Runtime.getRuntime().gc()會建議 JVM 進(jìn)行 FullGC。這里需要注意的點(diǎn)是只是建議，并非強(qiáng)制，但大多數(shù)情況下JVM都會執(zhí)行。為了避免開發(fā)人員濫用，通常我們會通過參數(shù)-XX:+DisableExplicitGC來禁止這種顯式的GC。

（4）內(nèi)存泄漏

雖然老年代總空間很大，但如果存在內(nèi)存泄漏，一些“垃圾對象”因?yàn)楸灰馔獾囊贸钟卸鵁o法被回收（典型的是ThreadLocal使用不當(dāng)就會出現(xiàn)內(nèi)存泄漏的問題）。每次YoungGC后，都有一批本應(yīng)被回收的對象因?yàn)樾孤┒黄冗M(jìn)入老年代，最終導(dǎo)致老年代中使用部分達(dá)到回收閾值，觸發(fā)FullGC。

（5）老年代碎片化嚴(yán)重

如果YoungGC后Survivor區(qū)存活對象正常的晉升到老年代，但老年代也因?yàn)樗槠瘒?yán)重而無法容納這些對象，即使總的剩余空間還很多，也會觸發(fā)FullGC來整理碎片。

偶爾一次FullGC沒問題，但是頻繁的FullGC或者FullGC的時間很長，這些問題都是需要我們關(guān)注的。

3、實(shí)際業(yè)務(wù)中常見的易導(dǎo)致FullGC場景

（1）雪崩效應(yīng)

在系統(tǒng)中依賴其他服務(wù)返回的響應(yīng)數(shù)據(jù)，如果其他服務(wù)返回響應(yīng)超時，容易導(dǎo)致當(dāng)前內(nèi)存中的數(shù)據(jù)激增而導(dǎo)致觸發(fā)FullGC。

（2）大對象分配

文件處理是常見業(yè)務(wù)場景，處理文件解析時候，如果用戶上傳一個上百兆的大文件，此時服務(wù)端一次性將其讀入內(nèi)存數(shù)組中，那么這個數(shù)組就是一個大對象，很可能直接在老年代分配。如果此時有多個用戶同時上傳大文件，就會迅速擠占老年代空間，進(jìn)而導(dǎo)致觸發(fā)FullGC。

（3）內(nèi)存泄漏

一個后臺任務(wù)系統(tǒng)，需要緩存一些任務(wù)執(zhí)行上下文，開發(fā)人中常見的處理方案是將這些上下文對象放入了一個靜態(tài)的HashMap中（或者ThreadLocal）。由于靜態(tài)集合的生命周期與類加載器相同（通常就是程序運(yùn)行期間），這些上下文對象永遠(yuǎn)無法被回收。隨著系統(tǒng)運(yùn)行，那么這個HashMap越來越大，最終老年代內(nèi)存不足，觸發(fā)頻繁的FullGC。

（4）資源未關(guān)閉

數(shù)據(jù)庫連接、文件流等資源未及時關(guān)閉雖然不是嚴(yán)格的內(nèi)存泄漏，但如果大量連接或流對象因?yàn)楫惓５仍驔]有被正確關(guān)閉，它們所關(guān)聯(lián)的Java對象和native memory就無法被及時釋放，也會導(dǎo)致內(nèi)存壓力激增，觸發(fā)頻繁的FullGC。