前言

近期被問(wèn)及這個(gè)問(wèn)題，在此記錄整理一下。

System.gc()方法的調(diào)用

此方法的調(diào)用是建議JVM進(jìn)行Full GC,雖然只是建議而非一定,但很多情況下它會(huì)觸發(fā) Full GC,從而增加Full GC的頻率,也即增加了間歇性停頓的次數(shù)。強(qiáng)烈影響系建議能不使用此方法就別使用，讓虛擬機(jī)自己去管理它的內(nèi)存，可通過(guò)通過(guò)-XX:+ DisableExplicitGC來(lái)禁止RMI調(diào)用System.gc。

老年代空間不足

老年代空間只有在新生代對(duì)象轉(zhuǎn)入及創(chuàng)建為大對(duì)象、大數(shù)組時(shí)才會(huì)出現(xiàn)不足的現(xiàn)象，當(dāng)執(zhí)行Full GC后空間仍然不足，則拋出如下錯(cuò)誤：

java.lang.OutOfMemoryError: Java heap space

為避免以上兩種狀況引起的Full GC，調(diào)優(yōu)時(shí)應(yīng)盡量做到讓對(duì)象在Minor GC階段被回收、讓對(duì)象在新生代多存活一段時(shí)間及不要?jiǎng)?chuàng)建過(guò)大的對(duì)象及數(shù)組。

永生區(qū)空間不足

JVM規(guī)范中運(yùn)行時(shí)數(shù)據(jù)區(qū)域中的方法區(qū)，在HotSpot虛擬機(jī)中又被習(xí)慣稱為永生代或者永生區(qū)，Permanet Generation中存放的為一些class的信息、常量、靜態(tài)變量等數(shù)據(jù)，當(dāng)系統(tǒng)中要加載的類、反射的類和調(diào)用的方法較多時(shí)，Permanet Generation可能會(huì)被占滿，在未配置為采用CMS GC的情況下也會(huì)執(zhí)行Full GC。如果經(jīng)過(guò)Full GC仍然回收不了，那么JVM會(huì)拋出如下錯(cuò)誤信息：
java.lang.OutOfMemoryError: PermGen space
為避免Perm Gen占滿造成Full GC現(xiàn)象，可采用的方法為增大Perm Gen空間或轉(zhuǎn)為使用CMS GC。

CMS GC時(shí)出現(xiàn)promotion failed和concurrent mode failure

對(duì)于采用CMS進(jìn)行老年代GC的程序而言，尤其要注意GC日志中是否有promotion failed和concurrent mode failure兩種狀況，當(dāng)這兩種狀況出現(xiàn)時(shí)可能會(huì)觸發(fā)Full GC。

promotion failed是在進(jìn)行Minor GC時(shí)，survivor space放不下、對(duì)象只能放入老年代，而此時(shí)老年代也放不下造成的；concurrent mode failure是在

執(zhí)行CMS GC的過(guò)程中同時(shí)有對(duì)象要放入老年代，而此時(shí)老年代空間不足造成的（有時(shí)候“空間不足”是CMS GC時(shí)當(dāng)前的浮動(dòng)垃圾過(guò)多導(dǎo)致暫時(shí)性的空間不足觸發(fā)Full GC）。

對(duì)措施為：增大survivor space、老年代空間或調(diào)低觸發(fā)并發(fā)GC的比率，但在JDK 5.0+、6.0+的版本中有可能會(huì)由于JDK的bug29導(dǎo)致CMS在remark完畢后很久才觸發(fā)sweeping動(dòng)作。對(duì)于這種狀況，可通過(guò)設(shè)置-XX: CMSMaxAbortablePrecleanTime=5（單位為ms）來(lái)避免。

統(tǒng)計(jì)得到的Minor GC晉升到舊生代的平均大小大于老年代的剩余空間這是一個(gè)較為復(fù)雜的觸發(fā)情況，Hotspot為了避免由于新生代對(duì)象晉升到舊生代導(dǎo)致舊生代空間不足的現(xiàn)象，在進(jìn)行Minor GC時(shí)，做了一個(gè)判斷，如果之前統(tǒng)計(jì)所得到的Minor GC晉升到舊生代的平均大小大于舊生代的剩余空間，那么就直接觸發(fā)Full GC。

例如程序第一次觸發(fā)Minor GC后，有6MB的對(duì)象晉升到舊生代，那么當(dāng)下一次Minor GC發(fā)生時(shí)，首先檢查舊生代的剩余空間是否大于6MB，如果小于6MB，則執(zhí)行Full GC。

當(dāng)新生代采用PS GC時(shí)，方式稍有不同，PS GC是在Minor GC后也會(huì)檢查，例如上面的例子中第一次Minor GC后，PS GC會(huì)檢查此時(shí)舊生代的剩余空間是否大于6MB，如小于，則觸發(fā)對(duì)舊生代的回收。

除了以上4種狀況外，對(duì)于使用RMI來(lái)進(jìn)行RPC或管理的Sun JDK應(yīng)用而言，默認(rèn)情況下會(huì)一小時(shí)執(zhí)行一次Full GC。可通過(guò)在啟動(dòng)時(shí)通過(guò)- java -

Dsun.rmi.dgc.client.gcInterval=3600000來(lái)設(shè)置Full GC執(zhí)行的間隔時(shí)間或通過(guò)-XX:+ DisableExplicitGC來(lái)禁止RMI調(diào)用System.gc。

堆中分配很大的對(duì)象

所謂大對(duì)象，是指需要大量連續(xù)內(nèi)存空間的java對(duì)象，例如很長(zhǎng)的數(shù)組，此種對(duì)象會(huì)直接進(jìn)入老年代，而老年代雖然有很大的剩余空間，但是無(wú)法找到足夠大的連續(xù)空間來(lái)分配給當(dāng)前對(duì)象，此種情況就會(huì)觸發(fā)JVM進(jìn)行Full GC。

為了解決這個(gè)問(wèn)題，CMS垃圾收集器提供了一個(gè)可配置的參數(shù)，即-XX:+UseCMSCompactAtFullCollection開關(guān)參數(shù)，用于在“享受”完Full GC服務(wù)之后額外免費(fèi)贈(zèng)送一個(gè)碎片整理的過(guò)程，內(nèi)存整理的過(guò)程無(wú)法并發(fā)的，空間碎片問(wèn)題沒有了，但提頓時(shí)間不得不變長(zhǎng)了，JVM設(shè)計(jì)者們還提供了另外一個(gè)參數(shù) -XX:CMSFullGCsBeforeCompaction,這個(gè)參數(shù)用于設(shè)置在執(zhí)行多少次不壓縮的Full GC后,跟著來(lái)一次帶壓縮的。

以上就是本文的全部?jī)?nèi)容，希望對(duì)大家的學(xué)習(xí)有所幫助，也希望大家多多支持腳本之家。

最新評(píng)論