JVM調優總結(五)-分代垃圾回收詳述1
轉自:
1.http://pengjiaheng.iteye.com/blog/524024
2.http://ifeve.com/jvm-yong-generation/
為什麼要分代
分代的垃圾回收策略,是基於這樣一個事實:不同的物件的生命週期是不一樣的。因此,不同生命週期的物件可以採取不同的收集方式,以便提高回收效率。其實不分代完全可以,分代的唯一理由就是優化GC效能,提高回收效率。
在Java程式執行的過程中,會產生大量的物件,其中有些物件是與業務資訊相關,比如Http請求中的Session物件、執行緒、Socket連線,這類物件跟業務直接掛鉤,因此生命週期比較長。但是還有一些物件,主要是程式執行過程中生成的臨時變數,這些物件生命週期會比較短,比如:String物件,由於其不變類的特性,系統會產生大量的這些物件,有些物件甚至只用一次即可回收。
試想,在不進行物件存活時間區分的情況下,每次垃圾回收都是對整個堆空間進行回收,花費時間相對會長,同時,因為每次回收都需要遍歷所有存活物件,但實際上,對於生命週期長的物件而言,這種遍歷是沒有效果的,因為可能進行了很多次遍歷,但是他們依舊存在。因此,分代垃圾回收採用分治的思想,進行代的劃分,把不同生命週期的物件放在不同代上,不同代上採用最適合它的垃圾回收方式進行回收。
如何分代
如圖所示:
虛擬機器中的共劃分為三個代:年輕代(Young Generation)、年老代(Old Generation)和持久代(Permanent Generation)。其中持久代主要存放的是Java類的類資訊,與垃圾收集要收集的Java物件關係不大。年輕代和年老代的劃分是對垃圾收集影響比較大的。
年輕代:
HotSpot JVM把年輕代分為了三部分:1個Eden區和2個Survivor區(分別叫from和to)。預設比例為8:1,為啥預設會是這個比例,接下來我們會聊到。一般情況下,新建立的物件都會被分配到Eden區(一些大物件特殊處理),這些物件經過第一次Minor GC後,如果仍然存活,將會被移到Survivor區。物件在Survivor區中每熬過一次Minor GC,年齡就會增加1歲,當它的年齡增加到一定程度時,就會被移動到年老代中。
因為年輕代中的物件基本都是朝生夕死的(80%以上),所以在年輕代的垃圾回收演算法使用的是複製演算法,複製演算法的基本思想就是將記憶體分為兩塊,每次只用其中一塊,當這一塊記憶體用完,就將還活著的物件複製到另外一塊上面。複製演算法不會產生記憶體碎片。
在GC開始的時候,物件只會存在於Eden區和名為“From”的Survivor區,Survivor區“To”是空的。緊接著進行GC,Eden區中所有存活的物件都會被複制到“To”,而在“From”區中,仍存活的物件會根據他們的年齡值來決定去向。年齡達到一定值(年齡閾值,可以通過-XX:MaxTenuringThreshold來設定)的物件會被移動到年老代中,沒有達到閾值的物件會被複制到“To”區域。經過這次GC後,Eden區和From區已經被清空。這個時候,“From”和“To”會交換他們的角色,也就是新的“To”就是上次GC前的“From”,新的“From”就是上次GC前的“To”。不管怎樣,都會保證名為To的Survivor區域是空的。Minor GC會一直重複這樣的過程,直到“To”區被填滿,“To”區被填滿之後,會將所有物件移動到年老代中。
年老代:
在年輕代中經歷了N次垃圾回收後仍然存活的物件,就會被放到年老代中。因此,可以認為年老代中存放的都是一些生命週期較長的物件。
持久代:
用於存放靜態檔案,如今Java類、方法等。持久代對垃圾回收沒有顯著影響,但是有些應用可能動態生成或者呼叫一些class,例如Hibernate等,在這種時候需要設定一個比較大的持久代空間來存放這些執行過程中新增的類。持久代大小通過-XX:MaxPermSize=<N>進行設定。
什麼情況下觸發垃圾回收
由於物件進行了分代處理,因此垃圾回收區域、時間也不一樣。GC有兩種型別:Scavenge GC和Full GC。
Minor GC
一般情況下,當新物件生成,並且在Eden申請空間失敗時,就會觸發Scavenge GC,對Eden區域進行GC,清除非存活物件,並且把尚且存活的物件移動到Survivor區。然後整理Survivor的兩個區。這種方式的GC是對年輕代的Eden區進行,不會影響到年老代。因為大部分物件都是從Eden區開始的,同時Eden區不會分配的很大,所以Eden區的GC會頻繁進行。因而,一般在這裡需要使用速度快、效率高的演算法,使Eden去能儘快空閒出來。
Full GC
對整個堆進行整理,包括Young、Tenured和Perm。Full GC因為需要對整個對進行回收,所以比Minor GC要慢,因此應該儘可能減少Full GC的次數。在對JVM調優的過程中,很大一部分工作就是對於FullGC的調節。有如下原因可能導致Full GC:
· 年老代(Tenured)被寫滿
· 持久代(Perm)被寫滿
· System.gc()被顯示呼叫
·上一次GC之後Heap的各域分配策略動態變化
相關文章
- JVM調優總結-分代垃圾回收詳述1JVM
- JVM調優總結-分代垃圾回收詳述2JVM
- JVM調優總結(六)-分代垃圾回收詳述2JVM
- JVM調優總結(九)-新一代的垃圾回收演算法JVM演算法
- JVM調優總結(三)-基本垃圾回收演算法JVM演算法
- JVM調優總結(四)-垃圾回收面臨的問題JVM
- jvm垃圾分代回收演算法JVM演算法
- JVM的垃圾回收機制詳解和調優JVM
- JVM調優:基本垃圾回收演算法JVM演算法
- JVM 記憶體分代、垃圾回收漫談JVM記憶體
- JVM垃圾回收詳解JVM
- 【JVM】垃圾回收器總結(2)——七種垃圾回收器型別JVM型別
- JVM系列(五) - JVM垃圾回收演算法JVM演算法
- 【淺度渣文】JVM——簡述垃圾回收JVM
- JVM - 方法區(永久代)的垃圾回收JVM
- JVM調優總結-調優方法JVM
- JVM調優之垃圾定位、垃圾回收演算法、垃圾處理器對比JVM演算法
- JVM中G1垃圾回收器詳細解析JVM
- JVM(五)垃圾回收器的前世今生JVM
- 深入理解JVM(五)——垃圾回收器JVM
- JVM調優總結-典型配置舉例1JVM
- JVM調優總結(十)-調優方法JVM
- JVM垃圾回收JVM
- jvm - 垃圾回收JVM
- [JVM]垃圾回收JVM
- ☕【JVM技術指南】「JVM總結筆記」Java虛擬機器垃圾回收認知和調優的"思南(司南)"【下部】JVM筆記Java虛擬機
- JVM調優總結(七)-典型配置舉例1JVM
- Java垃圾回收調優實戰Java
- JVM調優總結(十一)-反思JVM
- GC 分代回收 - 垃圾收集器GC
- JVM原理講解和調優,記憶體管理和垃圾回收,記憶體調優JVM記憶體
- 從原理聊JVM(三):詳解現代垃圾回收器Shenandoah和ZGCJVMNaNGC
- JVM垃圾回收概述JVM
- JVM垃圾回收(下)JVM
- JVM - 垃圾回收概述JVM
- JVM垃圾回收器JVM
- JVM調優:HotSpot JVM垃圾收集器JVMHotSpot
- 【JVM進階之路】十:JVM調優總結JVM