內(nèi)存碎片整理

每次執(zhí)行清除(sweeping), JVM 都必須保證不可達(dá)對(duì)象占用的內(nèi)存能被回收重用。但這(最終)有可能會(huì)產(chǎn)生內(nèi)存碎片(類似于磁盤(pán)碎片), 進(jìn)而引發(fā)兩個(gè)問(wèn)題:

寫(xiě)入操作越來(lái)越耗時(shí), 因?yàn)閷ふ乙粔K足夠大的空閑內(nèi)存會(huì)變得非常麻煩。

在創(chuàng)建新對(duì)象時(shí), JVM在連續(xù)的塊中分配內(nèi)存。如果碎片問(wèn)題很?chē)?yán)重, 直至沒(méi)有空閑片段能存放下新創(chuàng)建的對(duì)象,就會(huì)發(fā)生內(nèi)存分配錯(cuò)誤(allocation error)。

要避免這類問(wèn)題,JVM 必須確保碎片問(wèn)題不失控。因此在垃圾收集過(guò)程中, 不僅僅是標(biāo)記和清除, 還需要執(zhí)行 “內(nèi)存碎片整理” 過(guò)程。這個(gè)過(guò)程讓所有可達(dá)對(duì)象(reachable objects)依次排列, 以消除(或減少)碎片。示意圖如下所示:

分代假設(shè)

我們前面提到過(guò),執(zhí)行垃圾收集需要停止整個(gè)應(yīng)用。很明顯,對(duì)象越多則收集所有垃圾消耗的時(shí)間就越長(zhǎng)。但可不可以只處理一個(gè)較小的內(nèi)存區(qū)域呢? 為了探究這種可能性,研究人員發(fā)現(xiàn),程序中的大多數(shù)可回收的內(nèi)存可歸為兩類:

大部分對(duì)象很快就不再使用

還有一部分不會(huì)立即無(wú)用,但也不會(huì)持續(xù)(太)長(zhǎng)時(shí)間

這些觀測(cè)形成了 弱代假設(shè)(Weak Generational Hypothesis)。基于這一假設(shè), VM中的內(nèi)存被分為年輕代(Young Generation)和老年代(Old Generation)。老年代有時(shí)候也稱為 年老區(qū)(Tenured)。

拆分為這樣兩個(gè)可清理的單獨(dú)區(qū)域，允許采用不同的算法來(lái)大幅提高GC的性能。

這種方法也不是沒(méi)有問(wèn)題。例如，在不同分代中的對(duì)象可能會(huì)互相引用, 在收集某一個(gè)分代時(shí)就會(huì)成為 “事實(shí)上的” GC root。

當(dāng)然,要著重強(qiáng)調(diào)的是,分代假設(shè)并不適用于所有程序。因?yàn)镚C算法專門(mén)針對(duì)“要么死得快”，“否則活得長(zhǎng)” 這類特征的對(duì)象來(lái)進(jìn)行優(yōu)化, JVM對(duì)收集那種存活時(shí)間半長(zhǎng)不長(zhǎng)的對(duì)象就顯得非常尷尬了。

內(nèi)存池

堆內(nèi)存中的內(nèi)存池劃分也是類似的。不太容易理解的地方在于各個(gè)內(nèi)存池中的垃圾收集是如何運(yùn)行的。請(qǐng)注意,不同的GC算法在實(shí)現(xiàn)細(xì)節(jié)上可能會(huì)有所不同,但和本章所介紹的相關(guān)概念都是一致的。

新生代(Eden,伊甸園)

Eden 是內(nèi)存中的一個(gè)區(qū)域, 用來(lái)分配新創(chuàng)建的對(duì)象。通常會(huì)有多個(gè)線程同時(shí)創(chuàng)建多個(gè)對(duì)象, 所以 Eden 區(qū)被劃分為多個(gè) 線程本地分配緩沖區(qū)(Thread Local Allocation Buffer, 簡(jiǎn)稱TLAB)。通過(guò)這種緩沖區(qū)劃分,大部分對(duì)象直接由JVM 在對(duì)應(yīng)線程的TLAB中分配, 避免與其他線程的同步操作。

如果 TLAB 中沒(méi)有足夠的內(nèi)存空間, 就會(huì)在共享Eden區(qū)(shared Eden space)之中分配。如果共享Eden區(qū)也沒(méi)有足夠的空間, 就會(huì)觸發(fā)一次 年輕代GC 來(lái)釋放內(nèi)存空間。如果GC之后 Eden 區(qū)依然沒(méi)有足夠的空閑內(nèi)存區(qū)域, 則對(duì)象就會(huì)被分配到老年代空間(Old Generation)。

當(dāng) Eden 區(qū)進(jìn)行垃圾收集時(shí), GC將所有從 root 可達(dá)的對(duì)象過(guò)一遍, 并標(biāo)記為存活對(duì)象。

我們?cè)赋?對(duì)象間可能會(huì)有跨代的引用, 所以需要一種方法來(lái)標(biāo)記從其他分代中指向Eden的所有引用。這樣做又會(huì)遭遇各個(gè)分代之間一遍又一遍的引用。JVM在實(shí)現(xiàn)時(shí)采用了一些絕招: 卡片標(biāo)記(card-marking)。從本質(zhì)上講,JVM只需要記住Eden區(qū)中 “臟”對(duì)象的粗略位置, 可能有老年代的對(duì)象引用指向這部分區(qū)間。

標(biāo)記階段完成后, Eden中所有存活的對(duì)象都會(huì)被復(fù)制到存活區(qū)(Survivor spaces)里面。整個(gè)Eden區(qū)就可以被認(rèn)為是空的, 然后就能用來(lái)分配新對(duì)象。這種方法稱為 “標(biāo)記-復(fù)制”(Mark and Copy): 存活的對(duì)象被標(biāo)記, 然后復(fù)制到一個(gè)存活區(qū)(注意,是復(fù)制,而不是移動(dòng))。。

存活區(qū)

Eden 區(qū)的旁邊是兩個(gè)存活區(qū), 稱為 from 空間和 to 空間。需要著重強(qiáng)調(diào)的的是, 任意時(shí)刻總有一個(gè)存活區(qū)是空的(empty)。

空的那個(gè)存活區(qū)用于在下一次年輕代GC時(shí)存放收集的對(duì)象。年輕代中所有的存活對(duì)象(包括Edenq區(qū)和非空的那個(gè) “from” 存活區(qū))都會(huì)被復(fù)制到 ”to“ 存活區(qū)。GC過(guò)程完成后, ”to“ 區(qū)有對(duì)象,而 ‘from’ 區(qū)里沒(méi)有對(duì)象。兩者的角色進(jìn)行正好切換 。

存活的對(duì)象會(huì)在兩個(gè)存活區(qū)之間復(fù)制多次, 直到某些對(duì)象的存活 時(shí)間達(dá)到一定的閥值。分代理論假設(shè), 存活超過(guò)一定時(shí)間的對(duì)象很可能會(huì)繼續(xù)存活更長(zhǎng)時(shí)間。

這類“ 年老” 的對(duì)象因此被提升(promoted )到老年代。提升的時(shí)候， 存活區(qū)的對(duì)象不再是復(fù)制到另一個(gè)存活區(qū),而是遷移到老年代, 并在老年代一直駐留, 直到變?yōu)椴豢蛇_(dá)對(duì)象。

為了確定一個(gè)對(duì)象是否“足夠老”, 可以被提升(Promotion)到老年代，GC模塊跟蹤記錄每個(gè)存活區(qū)對(duì)象存活的次數(shù)。每次分代GC完成后,存活對(duì)象的年齡就會(huì)增長(zhǎng)。當(dāng)年齡超過(guò)提升閾值(tenuring threshold), 就會(huì)被提升到老年代區(qū)域。

具體的提升閾值由JVM動(dòng)態(tài)調(diào)整,但也可以用參數(shù) -XX:+MaxTenuringThreshold 來(lái)指定上限。如果設(shè)置 -XX:+MaxTenuringThreshold=0 , 則GC時(shí)存活對(duì)象不在存活區(qū)之間復(fù)制，直接提升到老年代?，F(xiàn)代 JVM 中這個(gè)閾值默認(rèn)設(shè)置為15個(gè) GC周期。這也是HotSpot中的最大值。

如果存活區(qū)空間不夠存放年輕代中的存活對(duì)象，提升(Promotion)也可能更早地進(jìn)行。

老年代(Old Generation)

老年代的GC實(shí)現(xiàn)要復(fù)雜得多。老年代內(nèi)存空間通常會(huì)更大，里面的對(duì)象是垃圾的概率也更小。

老年代GC發(fā)生的頻率比年輕代小很多。同時(shí), 因?yàn)轭A(yù)期老年代中的對(duì)象大部分是存活的, 所以不再使用標(biāo)記和復(fù)制(Mark and Copy)算法。而是采用移動(dòng)對(duì)象的方式來(lái)實(shí)現(xiàn)最小化內(nèi)存碎片。老年代空間的清理算法通常是建立在不同的基礎(chǔ)上的。原則上,會(huì)執(zhí)行以下這些步驟:

通過(guò)標(biāo)志位(marked bit),標(biāo)記所有通過(guò) GC roots 可達(dá)的對(duì)象.

刪除所有不可達(dá)對(duì)象

整理老年代空間中的內(nèi)容，方法是將所有的存活對(duì)象復(fù)制,從老年代空間開(kāi)始的地方,依次存放。

通過(guò)上面的描述可知, 老年代GC必須明確地進(jìn)行整理,以避免內(nèi)存碎片過(guò)多。

永久代(PermGen)

在Java 8 之前有一個(gè)特殊的空間,稱為“永久代”(Permanent Generation)。這是存儲(chǔ)元數(shù)據(jù)(metadata)的地方,比如 class 信息等。此外,這個(gè)區(qū)域中也保存有其他的數(shù)據(jù)和信息, 包括 內(nèi)部化的字符串(internalized strings)等等。實(shí)際上這給Java開(kāi)發(fā)者造成了很多麻煩,因?yàn)楹茈y去計(jì)算這塊區(qū)域到底需要占用多少內(nèi)存空間。

預(yù)測(cè)失敗導(dǎo)致的結(jié)果就是產(chǎn)生 java.lang.OutOfMemoryError: Permgen space 這種形式的錯(cuò)誤。

除非 ·OutOfMemoryError· 確實(shí)是內(nèi)存泄漏導(dǎo)致的,否則就只能增加 permgen 的大小，例如下面的示例，就是設(shè)置 permgen 最大空間為 256 MB:

java -XX:MaxPermSize=256m com.mycompany.MyApplication

元空間

既然估算元數(shù)據(jù)所需空間那么復(fù)雜, Java 8直接刪除了永久代(Permanent Generation)，改用 Metaspace。從此以后, Java 中很多雜七雜八的東西都放置到普通的堆內(nèi)存里。

當(dāng)然，像類定義(class definitions)之類的信息會(huì)被加載到 Metaspace 中。元數(shù)據(jù)區(qū)位于本地內(nèi)存(native memory),不再影響到普通的Java對(duì)象。默認(rèn)情況下, Metaspace的大小只受限于 Java進(jìn)程可用的本地內(nèi)存。

這樣程序就不再因?yàn)槎嗉虞d了幾個(gè)類/JAR包就導(dǎo)致 java.lang.OutOfMemoryError: Permgen space. 

注意, 這種不受限制的空間也不是沒(méi)有代價(jià)的 —— 如果 Metaspace 失控, 則可能會(huì)導(dǎo)致很?chē)?yán)重的內(nèi)存交換(swapping), 或者導(dǎo)致本地內(nèi)存分配失敗。

如果需要避免這種最壞情況，那么可以通過(guò)下面這樣的方式來(lái)限制 Metaspace 的大小, 如 256 MB:

java -XX:MaxMetaspaceSize=256m com.mycompany.MyApplication

Minor GC vs Major GC vs Full GC

垃圾收集事件(Garbage Collection events)通常分為: 小型GC(Minor GC) - 大型GC(Major GC) - 和完全GC(Full GC) 。本節(jié)介紹這些事件及其區(qū)別。然后你會(huì)發(fā)現(xiàn)這些區(qū)別也不是特別清晰。

最重要的是,應(yīng)用程序是否滿足 服務(wù)級(jí)別協(xié)議(Service Level Agreement, SLA), 并通過(guò)監(jiān)控程序查看響應(yīng)延遲和吞吐量。也只有那時(shí)候才能看到GC事件相關(guān)的結(jié)果。重要的是這些事件是否停止整個(gè)程序,以及持續(xù)多長(zhǎng)時(shí)間。

雖然 Minor, Major 和 Full GC 這些術(shù)語(yǔ)被廣泛應(yīng)用, 但并沒(méi)有標(biāo)準(zhǔn)的定義, 我們還是來(lái)深入了解一下具體的細(xì)節(jié)吧。

小型GC(Minor GC)

年輕代內(nèi)存的垃圾收集事件稱為小型GC。這個(gè)定義既清晰又得到廣泛共識(shí)。對(duì)于小型GC事件,有一些有趣的事情你應(yīng)該了解一下:

• 當(dāng)JVM無(wú)法為新對(duì)象分配內(nèi)存空間時(shí)總會(huì)觸發(fā) Minor GC,比如 Eden 區(qū)占滿時(shí)。所以(新對(duì)象)分配頻率越高, Minor GC 的頻率就越高。
• Minor GC 事件實(shí)際上忽略了老年代。從老年代指向年輕代的引用都被認(rèn)為是GC Root。而從年輕代指向老年代的引用在標(biāo)記階段全部被忽略。
• 與一般的認(rèn)識(shí)相反, Minor GC 每次都會(huì)引起全線停頓(stop-the-world ), 暫停所有的應(yīng)用線程。對(duì)大多數(shù)程序而言,暫停時(shí)長(zhǎng)基本上是可以忽略不計(jì)的, 因?yàn)?Eden 區(qū)的對(duì)象基本上都是垃圾, 也不怎么復(fù)制到存活區(qū)/老年代。如果情況不是這樣, 大部分新創(chuàng)建的對(duì)象不能被垃圾回收清理掉, 則 Minor GC的停頓就會(huì)持續(xù)更長(zhǎng)的時(shí)間。

所以 Minor GC 的定義很簡(jiǎn)單 —— Minor GC 清理的就是年輕代。

Major GC vs Full GC

值得一提的是, 這些術(shù)語(yǔ)并沒(méi)有正式的定義 —— 無(wú)論是在JVM規(guī)范還是在GC相關(guān)論文中。

我們知道, Minor GC 清理的是年輕代空間(Young space)，相應(yīng)的,其他定義也很簡(jiǎn)單:

• Major GC(大型GC) 清理的是老年代空間(Old space)。
• Full GC(完全GC)清理的是整個(gè)堆, 包括年輕代和老年代空間。

杯具的是更復(fù)雜的情況出現(xiàn)了。很多 Major GC 是由 Minor GC 觸發(fā)的, 所以很多情況下這兩者是不可分離的。另一方面, 像G1這樣的垃圾收集算法執(zhí)行的是部分區(qū)域垃圾回收, 所以，額，使用術(shù)語(yǔ)“cleaning”并不是非常準(zhǔn)確。

這也讓我們認(rèn)識(shí)到,不應(yīng)該去操心是叫 Major GC 呢還是叫 Full GC, 我們應(yīng)該關(guān)注的是: 某次GC事件 是否停止所有線程,或者是與其他線程并發(fā)執(zhí)行。

這些混淆甚至根植于標(biāo)準(zhǔn)的JVM工具中。我的意思可以通過(guò)實(shí)例來(lái)說(shuō)明。讓我們來(lái)對(duì)比同一JVM中兩款工具的GC信息輸出吧。這個(gè)JVM使用的是 并發(fā)標(biāo)記和清除收集器（Concurrent Mark and Sweep collector，-XX:+UseConcMarkSweepGC).

my-precious: me$ jstat -gc -t 4235 1s

Time S0C    S1C    S0U    S1U      EC       EU        OC         OU       MC     MU    CCSC   CCSU   YGC     YGCT    FGC    FGCT     GCT   
 5.7 34048.0 34048.0  0.0   34048.0 272640.0 194699.7 1756416.0   181419.9  18304.0 17865.1 2688.0 2497.6      3    0.275   0      0.000    0.275
 6.7 34048.0 34048.0 34048.0  0.0   272640.0 247555.4 1756416.0   263447.9  18816.0 18123.3 2688.0 2523.1      4    0.359   0      0.000    0.359
 7.7 34048.0 34048.0  0.0   34048.0 272640.0 257729.3 1756416.0   345109.8  19072.0 18396.6 2688.0 2550.3      5    0.451   0      0.000    0.451
 8.7 34048.0 34048.0 34048.0 34048.0 272640.0 272640.0 1756416.0  444982.5  19456.0 18681.3 2816.0 2575.8      7    0.550   0      0.000    0.550
 9.7 34048.0 34048.0 34046.7  0.0   272640.0 16777.0  1756416.0   587906.3  20096.0 19235.1 2944.0 2631.8      8    0.720   0      0.000    0.720
10.7 34048.0 34048.0  0.0   34046.2 272640.0 80171.6  1756416.0   664913.4  20352.0 19495.9 2944.0 2657.4      9    0.810   0      0.000    0.810
11.7 34048.0 34048.0 34048.0  0.0   272640.0 129480.8 1756416.0   745100.2  20608.0 19704.5 2944.0 2678.4     10    0.896   0      0.000    0.896
12.7 34048.0 34048.0  0.0   34046.6 272640.0 164070.7 1756416.0   822073.7  20992.0 19937.1 3072.0 2702.8     11    0.978   0      0.000    0.978
<strong>13.7 34048.0 34048.0 34048.0  0.0   272640.0 211949.9 1756416.0   897364.4  21248.0 20179.6 3072.0 2728.1     12    1.087   1      0.004    1.091
14.7 34048.0 34048.0  0.0   34047.1 272640.0 245801.5 1756416.0   597362.6  21504.0 20390.6 3072.0 2750.3     13    1.183   2      0.050    1.233</strong>
15.7 34048.0 34048.0  0.0   34048.0 272640.0 21474.1  1756416.0   757347.0  22012.0 20792.0 3200.0 2791.0     15    1.336   2      0.050    1.386
16.7 34048.0 34048.0 34047.0  0.0   272640.0 48378.0  1756416.0   838594.4  22268.0 21003.5 3200.0 2813.2     16    1.433   2      0.050    1.484

此片段截取自JVM啟動(dòng)后的前17秒。根據(jù)這些信息可以得知: 有2次Full GC在12次Minor GC(YGC)之后觸發(fā)執(zhí)行, 總計(jì)耗時(shí) 50ms。當(dāng)然,也可以通過(guò)具備圖形界面的工具得出同樣的信息, 比如 jconsole 或者 jvisualvm (或者最新的 jmc)。

在下結(jié)論之前, 讓我們看看此JVM進(jìn)程的GC日志。顯然需要配置 -XX:+PrintGCDetails 參數(shù),GC日志的內(nèi)容更詳細(xì),結(jié)果也有一些不同:

java -XX:+PrintGCDetails -XX:+UseConcMarkSweepGC eu.plumbr.demo.GarbageProducer

3.157: [GC (Allocation Failure) 3.157: [ParNew: 272640K->34048K(306688K), 0.0844702 secs] 272640K->69574K(2063104K), 0.0845560 secs] [Times: user=0.23 sys=0.03, real=0.09 secs] 
4.092: [GC (Allocation Failure) 4.092: [ParNew: 306688K->34048K(306688K), 0.1013723 secs] 342214K->136584K(2063104K), 0.1014307 secs] [Times: user=0.25 sys=0.05, real=0.10 secs] 
... cut for brevity ...
11.292: [GC (Allocation Failure) 11.292: [ParNew: 306686K->34048K(306688K), 0.0857219 secs] 971599K->779148K(2063104K), 0.0857875 secs] [Times: user=0.26 sys=0.04, real=0.09 secs] 
12.140: [GC (Allocation Failure) 12.140: [ParNew: 306688K->34046K(306688K), 0.0821774 secs] 1051788K->856120K(2063104K), 0.0822400 secs] [Times: user=0.25 sys=0.03, real=0.08 secs] 
12.989: [GC (Allocation Failure) 12.989: [ParNew: 306686K->34048K(306688K), 0.1086667 secs] 1128760K->931412K(2063104K), 0.1087416 secs] [Times: user=0.24 sys=0.04, real=0.11 secs] 
13.098: [<strong>GC (CMS Initial Mark)</strong> [1 CMS-initial-mark: 897364K(1756416K)] 936667K(2063104K), <strong>0.0041705 secs</strong>] [Times: user=0.02 sys=0.00, real=0.00 secs] 
13.102: [CMS-concurrent-mark-start]
13.341: [CMS-concurrent-mark: 0.238/0.238 secs] [Times: user=0.36 sys=0.01, real=0.24 secs] 
13.341: [CMS-concurrent-preclean-start]
13.350: [CMS-concurrent-preclean: 0.009/0.009 secs] [Times: user=0.03 sys=0.00, real=0.01 secs] 
13.350: [CMS-concurrent-abortable-preclean-start]
13.878: [GC (Allocation Failure) 13.878: [ParNew: 306688K->34047K(306688K), 0.0960456 secs] 1204052K->1010638K(2063104K), 0.0961542 secs] [Times: user=0.29 sys=0.04, real=0.09 secs] 
14.366: [CMS-concurrent-abortable-preclean: 0.917/1.016 secs] [Times: user=2.22 sys=0.07, real=1.01 secs] 
14.366: [<strong>GC (CMS Final Remark)</strong> [YG occupancy: 182593 K (306688 K)]14.366: [Rescan (parallel) , 0.0291598 secs]14.395: [weak refs processing, 0.0000232 secs]14.395: [class unloading, 0.0117661 secs]14.407: [scrub symbol table, 0.0015323 secs]14.409: [scrub string table, 0.0003221 secs][1 CMS-remark: 976591K(1756416K)] 1159184K(2063104K), <strong>0.0462010 secs</strong>] [Times: user=0.14 sys=0.00, real=0.05 secs] 
14.412: [CMS-concurrent-sweep-start]
14.633: [CMS-concurrent-sweep: 0.221/0.221 secs] [Times: user=0.37 sys=0.00, real=0.22 secs] 
14.633: [CMS-concurrent-reset-start]
14.636: [CMS-concurrent-reset: 0.002/0.002 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]

通過(guò)GC日志可以看到, 在12 次 Minor GC之后發(fā)生了一些 “不同的事情”。并不是兩個(gè) Full GC, 而是在老年代執(zhí)行了一次 GC, 分為多個(gè)階段執(zhí)行:

• 初始標(biāo)記階段(Initial Mark phase),耗時(shí) 0.0041705秒(約4ms)。此階段是全線停頓(STW)事件,暫停所有應(yīng)用線程,以便執(zhí)行初始標(biāo)記。
• 標(biāo)記和預(yù)清理階段(Markup and Preclean phase)。和應(yīng)用線程并發(fā)執(zhí)行。
• 最終標(biāo)記階段(Final Remark phase), 耗時(shí) 0.0462010秒(約46ms)。此階段也是全線停頓(STW)事件。
• 清除操作(Sweep)是并發(fā)執(zhí)行的, 不需要暫停應(yīng)用線程。

所以從實(shí)際的GC日志可以看到, 并不是執(zhí)行了兩次 Full GC操作, 而是只執(zhí)行了一次清理老年代空間的 Major GC 。

如果只關(guān)心延遲, 通過(guò)后面 jstat 顯示的數(shù)據(jù), 也能得出正確的結(jié)果。它正確地列出了兩次 STW 事件,總計(jì)耗時(shí) 50 ms。這段時(shí)間影響了所有應(yīng)用線程的延遲。如果想要優(yōu)化吞吐量, 這個(gè)結(jié)果就會(huì)有誤導(dǎo)性 —— jstat 只列出了 stop-the-world 的初始標(biāo)記階段和最終標(biāo)記階段, jstat 的輸出完全隱藏了并發(fā)執(zhí)行的GC階段。

以上就是GC參考手冊(cè)二java中垃圾回收原理解析的詳細(xì)內(nèi)容，更多關(guān)于GC參考手冊(cè)java垃圾回收的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！

原文鏈接：https://plumbr.io/handbook/garbage-collection-in-java