Java full gc觸發(fā)情況實例解析
前言
近期被問及這個問題,在此記錄整理一下。
System.gc()方法的調(diào)用
此方法的調(diào)用是建議JVM進行Full GC,雖然只是建議而非一定,但很多情況下它會觸發(fā) Full GC,從而增加Full GC的頻率,也即增加了間歇性停頓的次數(shù)。強烈影響系建議能不使用此方法就別使用,讓虛擬機自己去管理它的內(nèi)存,可通過通過-XX:+ DisableExplicitGC來禁止RMI調(diào)用System.gc。
老年代空間不足
老年代空間只有在新生代對象轉入及創(chuàng)建為大對象、大數(shù)組時才會出現(xiàn)不足的現(xiàn)象,當執(zhí)行Full GC后空間仍然不足,則拋出如下錯誤:
java.lang.OutOfMemoryError: Java heap space
為避免以上兩種狀況引起的Full GC,調(diào)優(yōu)時應盡量做到讓對象在Minor GC階段被回收、讓對象在新生代多存活一段時間及不要創(chuàng)建過大的對象及數(shù)組。
永生區(qū)空間不足
JVM規(guī)范中運行時數(shù)據(jù)區(qū)域中的方法區(qū),在HotSpot虛擬機中又被習慣稱為永生代或者永生區(qū),Permanet Generation中存放的為一些class的信息、常量、靜態(tài)變量等數(shù)據(jù),當系統(tǒng)中要加載的類、反射的類和調(diào)用的方法較多時,Permanet Generation可能會被占滿,在未配置為采用CMS GC的情況下也會執(zhí)行Full GC。如果經(jīng)過Full GC仍然回收不了,那么JVM會拋出如下錯誤信息:
java.lang.OutOfMemoryError: PermGen space
為避免Perm Gen占滿造成Full GC現(xiàn)象,可采用的方法為增大Perm Gen空間或轉為使用CMS GC。
CMS GC時出現(xiàn)promotion failed和concurrent mode failure
對于采用CMS進行老年代GC的程序而言,尤其要注意GC日志中是否有promotion failed和concurrent mode failure兩種狀況,當這兩種狀況出現(xiàn)時可能會觸發(fā)Full GC。
promotion failed是在進行Minor GC時,survivor space放不下、對象只能放入老年代,而此時老年代也放不下造成的;concurrent mode failure是在
執(zhí)行CMS GC的過程中同時有對象要放入老年代,而此時老年代空間不足造成的(有時候“空間不足”是CMS GC時當前的浮動垃圾過多導致暫時性的空間不足觸發(fā)Full GC)。
對措施為:增大survivor space、老年代空間或調(diào)低觸發(fā)并發(fā)GC的比率,但在JDK 5.0+、6.0+的版本中有可能會由于JDK的bug29導致CMS在remark完畢后很久才觸發(fā)sweeping動作。對于這種狀況,可通過設置-XX: CMSMaxAbortablePrecleanTime=5(單位為ms)來避免。
統(tǒng)計得到的Minor GC晉升到舊生代的平均大小大于老年代的剩余空間這是一個較為復雜的觸發(fā)情況,Hotspot為了避免由于新生代對象晉升到舊生代導致舊生代空間不足的現(xiàn)象,在進行Minor GC時,做了一個判斷,如果之前統(tǒng)計所得到的Minor GC晉升到舊生代的平均大小大于舊生代的剩余空間,那么就直接觸發(fā)Full GC。
例如程序第一次觸發(fā)Minor GC后,有6MB的對象晉升到舊生代,那么當下一次Minor GC發(fā)生時,首先檢查舊生代的剩余空間是否大于6MB,如果小于6MB,則執(zhí)行Full GC。
當新生代采用PS GC時,方式稍有不同,PS GC是在Minor GC后也會檢查,例如上面的例子中第一次Minor GC后,PS GC會檢查此時舊生代的剩余空間是否大于6MB,如小于,則觸發(fā)對舊生代的回收。
除了以上4種狀況外,對于使用RMI來進行RPC或管理的Sun JDK應用而言,默認情況下會一小時執(zhí)行一次Full GC。可通過在啟動時通過- java -
Dsun.rmi.dgc.client.gcInterval=3600000來設置Full GC執(zhí)行的間隔時間或通過-XX:+ DisableExplicitGC來禁止RMI調(diào)用System.gc。
堆中分配很大的對象
所謂大對象,是指需要大量連續(xù)內(nèi)存空間的java對象,例如很長的數(shù)組,此種對象會直接進入老年代,而老年代雖然有很大的剩余空間,但是無法找到足夠大的連續(xù)空間來分配給當前對象,此種情況就會觸發(fā)JVM進行Full GC。
為了解決這個問題,CMS垃圾收集器提供了一個可配置的參數(shù),即-XX:+UseCMSCompactAtFullCollection開關參數(shù),用于在“享受”完Full GC服務之后額外免費贈送一個碎片整理的過程,內(nèi)存整理的過程無法并發(fā)的,空間碎片問題沒有了,但提頓時間不得不變長了,JVM設計者們還提供了另外一個參數(shù) -XX:CMSFullGCsBeforeCompaction,這個參數(shù)用于設置在執(zhí)行多少次不壓縮的Full GC后,跟著來一次帶壓縮的。
以上就是本文的全部內(nèi)容,希望對大家的學習有所幫助,也希望大家多多支持腳本之家。
相關文章
SpringBoot整合SQLite數(shù)據(jù)庫全過程
sqlite是一個很輕量級的數(shù)據(jù)庫,可以滿足日常sql的需求,下面這篇文章主要給大家介紹了關于SpringBoot整合SQLite數(shù)據(jù)庫的相關資料,文中通過實例代碼介紹的非常詳細,需要的朋友可以參考下2023-03-03