GC

垃圾回收概述

Java 和 C語言最大的區(qū)別，就在于，垃圾回收和內(nèi)存動態(tài)分配上。C語言沒有垃圾回收技術(shù)，需要程序員手動回收。

1960年，第一門開始使用內(nèi)存動態(tài)分配和垃圾收集技術(shù)的Lisp語言誕生。

關(guān)于垃圾收集有三個經(jīng)典問題：

• 哪些內(nèi)存需要回收？
• 什么時候回收？
• 如何回收？

大廠面試題

螞蟻金服

你知道哪幾種垃圾回收器，各自的優(yōu)缺點(diǎn)，重點(diǎn)講一下CMS和G1？

JVM GC算法有哪些，目前的JDK版本采用什么回收算法？

G1回收器講下回收過程GC是什么？為什么要有GC？

GC的兩種判定方法？CMS收集器與G1收集器的特點(diǎn)

百度

說一下GC算法，分代回收說下

垃圾收集策略和算法

天貓

JVM GC原理，JVM怎么回收內(nèi)存

CMS特點(diǎn)，垃圾回收算法有哪些？各自的優(yōu)缺點(diǎn)，他們共同的缺點(diǎn)是什么？

滴滴

Java的垃圾回收器都有哪些，說下G1的應(yīng)用場景，平時你是如何搭配使用垃圾回收器的

京東

你知道哪幾種垃圾收集器，各自的優(yōu)缺點(diǎn)，重點(diǎn)講下CMS和G1，

包括原理，流程，優(yōu)缺點(diǎn)。垃圾回收算法的實(shí)現(xiàn)原理

阿里

講一講垃圾回收算法。

什么情況下觸發(fā)垃圾回收？

如何選擇合適的垃圾收集算法？

JVM有哪三種垃圾回收器？

字節(jié)跳動

常見的垃圾回收器算法有哪些，各有什么優(yōu)劣？

System.gc()和Runtime.gc()會做什么事情？

Java GC機(jī)制？GC Roots有哪些？

Java對象的回收方式，回收算法。

CMS和G1了解么，CMS解決什么問題，說一下回收的過程。

CMS回收停頓了幾次，為什么要停頓兩次?

什么是垃圾？

垃圾是指在運(yùn)行程序中沒有任何指針指向的對象

如果不及時回收，垃圾一直占用內(nèi)存空間，可能導(dǎo)致內(nèi)存溢出錯誤

為什么需要GC？

想要學(xué)習(xí)GC，首先需要理解為什么需要GC？

對于高級語言來說，一個基本認(rèn)知是如果不進(jìn)行垃圾回收，內(nèi)存遲早都會被消耗完，因?yàn)椴粩嗟胤峙鋬?nèi)存空間而不進(jìn)行回收，就好像不停地生產(chǎn)生活垃圾而從來不打掃一樣。

除了釋放沒用的對象，垃圾回收也可以清除內(nèi)存里的記錄碎片。碎片整理將所占用的堆內(nèi)存移到堆的一端，以便JVM將整理出的內(nèi)存分配給新的對象。

隨著應(yīng)用程序所應(yīng)付的業(yè)務(wù)越來越龐大、復(fù)雜，用戶越來越多，沒有GC就不能保證應(yīng)用程序的正常進(jìn)行。而經(jīng)常造成STW的GC又跟不上實(shí)際的需求，所以才會不斷地嘗試對GC進(jìn)行優(yōu)化。

早期垃圾回收

在早期的C/C++時代，垃圾回收基本上是手工進(jìn)行的。開發(fā)人員可以使用new關(guān)鍵字進(jìn)行內(nèi)存申請，并使用delete關(guān)鍵字進(jìn)行內(nèi)存釋放。比如以下代碼：

MibBridge *pBridge= new cmBaseGroupBridge（）；//如果注冊失敗，使用Delete釋放該對象所占內(nèi)存區(qū)域if（pBridge->Register（kDestroy）！=NO ERROR）delete pBridge；

這種方式可以靈活控制內(nèi)存釋放的時間，但是會給開發(fā)人員帶來頻繁申請和釋放內(nèi)存的管理負(fù)擔(dān)。倘若有一處內(nèi)存區(qū)間由于程序員編碼的問題忘記被回收，那么就會產(chǎn)生內(nèi)存泄漏，垃圾對象永遠(yuǎn)無法被清除，隨著系統(tǒng)運(yùn)行時間的不斷增長，垃圾對象所耗內(nèi)存可能持續(xù)上升，直到出現(xiàn)內(nèi)存溢出并造成應(yīng)用程序崩潰。

有了垃圾回收機(jī)制后，上述代碼極有可能變成這樣

MibBridge *pBridge=new cmBaseGroupBridge(); pBridge->Register(kDestroy);

現(xiàn)在，除了Java以外，C#、Python、Ruby等語言都使用了自動垃圾回收的思想，也是未來發(fā)展趨勢，可以說這種自動化的內(nèi)存分配和來及回收方式已經(jīng)成為了現(xiàn)代開發(fā)語言必備的標(biāo)準(zhǔn)。

Java 垃圾回收機(jī)制

自動內(nèi)存管理

官網(wǎng)介紹：https://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/toc.html

自動內(nèi)存管理的優(yōu)點(diǎn)

自動內(nèi)存管理，無需開發(fā)人員手動參與內(nèi)存的分配與回收，這樣降低內(nèi)存泄漏和內(nèi)存溢出的風(fēng)險

沒有垃圾回收器，java也會和cpp一樣，各種懸垂指針，野指針，泄露問題讓你頭疼不已。

自動內(nèi)存管理機(jī)制，將程序員從繁重的內(nèi)存管理中釋放出來，可以更專心地專注于業(yè)務(wù)開發(fā)

關(guān)于自動內(nèi)存管理的擔(dān)憂

對于Java開發(fā)人員而言，自動內(nèi)存管理就像是一個黑匣子，如果過度依賴于“自動”，那么這將會是一場災(zāi)難，最嚴(yán)重的就會弱化Java開發(fā)人員在程序出現(xiàn)內(nèi)存溢出時定位問題和解決問題的能力。

此時，了解JVM的自動內(nèi)存分配和內(nèi)存回收原理就顯得非常重要，只有在真正了解JVM是如何管理內(nèi)存后，我們才能夠在遇見OutofMemoryError時，快速地根據(jù)錯誤異常日志定位問題和解決問題。

當(dāng)需要排查各種內(nèi)存溢出、內(nèi)存泄漏問題時，當(dāng)垃圾收集成為系統(tǒng)達(dá)到更高并發(fā)量的瓶頸時，我們就必須對這些“自動化”的技術(shù)實(shí)施必要的監(jiān)控和調(diào)節(jié)。

應(yīng)該關(guān)心哪些區(qū)域的回收？


垃圾收集器可以對年輕代回收，也可以對老年代回收，甚至是全棧和方法區(qū)的回收，

其中，Java堆是垃圾收集器的工作重點(diǎn)

從次數(shù)上講：

頻繁收集Young區(qū)

較少收集Old區(qū)

基本不收集Perm區(qū)（元空間）

垃圾回收相關(guān)算法

標(biāo)記階段：引用計數(shù)算法

標(biāo)記階段的目的

垃圾標(biāo)記階段：主要是為了判斷對象是否存活

在堆里存放著幾乎所有的Java對象實(shí)例，在GC執(zhí)行垃圾回收之前，首先需要區(qū)分出內(nèi)存中哪些是存活對象，哪些是已經(jīng)死亡的對象。只有被標(biāo)記為己經(jīng)死亡的對象，GC才會在執(zhí)行垃圾回收時，釋放掉其所占用的內(nèi)存空間，因此這個過程我們可以稱為垃圾標(biāo)記階段。

那么在JVM中究竟是如何標(biāo)記一個死亡對象呢？簡單來說，當(dāng)一個對象已經(jīng)不再被任何的存活對象繼續(xù)引用時，就可以宣判為已經(jīng)死亡。

判斷對象存活一般有兩種方式：引用計數(shù)算法和可達(dá)性分析算法。

引用計數(shù)算法

引用計數(shù)算法（Reference Counting）比較簡單，對每個對象保存一個整型的引用計數(shù)器屬性。用于記錄對象被引用的情況。

對于一個對象A，只要有任何一個對象引用了A，則A的引用計數(shù)器就加1；當(dāng)引用失效時，引用計數(shù)器就減1。只要對象A的引用計數(shù)器的值為0，即表示對象A不可能再被使用，可進(jìn)行回收。

優(yōu)點(diǎn)：實(shí)現(xiàn)簡單，垃圾對象便于辨識；判定效率高，回收沒有延遲性。

缺點(diǎn)：

它需要單獨(dú)的字段存儲計數(shù)器，這樣的做法增加了存儲空間的開銷。

每次賦值都需要更新計數(shù)器，伴隨著加法和減法操作，這增加了時間開銷。

引用計數(shù)器有一個嚴(yán)重的問題，即無法處理循環(huán)引用的情況。這是一條致命缺陷，導(dǎo)致在Java的垃圾回收器中沒有使用這類算法。

循環(huán)引用


當(dāng)p的指針斷開的時候，內(nèi)部的引用形成一個循環(huán)，計數(shù)器都還算1，無法被回收，這就是循環(huán)引用，從而造成內(nèi)存泄漏

證明：java使用的不是引用計數(shù)算法

/*** -XX:+PrintGCDetails* 證明：java使用的不是引用計數(shù)算法*/ public class RefCountGC {//這個成員屬性唯一的作用就是占用一點(diǎn)內(nèi)存private byte[] bigSize = new byte[5 * 1024 * 1024];//5MBObject reference = null;public static void main(String[] args) {RefCountGC obj1 = new RefCountGC();RefCountGC obj2 = new RefCountGC();obj1.reference = obj2;obj2.reference = obj1;obj1 = null;obj2 = null;//顯式的執(zhí)行垃圾回收行為//這里發(fā)生GC，obj1和obj2能否被回收？System.gc();} }


• 如果不小心直接把obj1.reference和obj2.reference置為null。則在Java堆中的兩塊內(nèi)存依然保持著互相引用，無法被回收

沒有進(jìn)行GC時

把下面的幾行代碼注釋掉，讓它來不及

System.gc();//把這行代碼注釋掉 HeapPSYoungGen total 38400K, used 14234K [0x00000000d5f80000, 0x00000000d8a00000, 0x0000000100000000)eden space 33280K, 42% used [0x00000000d5f80000,0x00000000d6d66be8,0x00000000d8000000)from space 5120K, 0% used [0x00000000d8500000,0x00000000d8500000,0x00000000d8a00000)to space 5120K, 0% used [0x00000000d8000000,0x00000000d8000000,0x00000000d8500000)ParOldGen total 87552K, used 0K [0x0000000081e00000, 0x0000000087380000, 0x00000000d5f80000)object space 87552K, 0% used [0x0000000081e00000,0x0000000081e00000,0x0000000087380000)Metaspace used 3496K, capacity 4498K, committed 4864K, reserved 1056768Kclass space used 387K, capacity 390K, committed 512K, reserved 1048576KProcess finished with exit code 0

進(jìn)行GC

打開那行代碼的注釋

[GC (System.gc()) [PSYoungGen: 13569K->808K(38400K)] 13569K->816K(125952K), 0.0012717 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] [Full GC (System.gc()) [PSYoungGen: 808K->0K(38400K)] [ParOldGen: 8K->670K(87552K)] 816K->670K(125952K), [Metaspace: 3491K->3491K(1056768K)], 0.0051769 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] HeapPSYoungGen total 38400K, used 333K [0x00000000d5f80000, 0x00000000d8a00000, 0x0000000100000000)eden space 33280K, 1% used [0x00000000d5f80000,0x00000000d5fd34a8,0x00000000d8000000)from space 5120K, 0% used [0x00000000d8000000,0x00000000d8000000,0x00000000d8500000)to space 5120K, 0% used [0x00000000d8500000,0x00000000d8500000,0x00000000d8a00000)ParOldGen total 87552K, used 670K [0x0000000081e00000, 0x0000000087380000, 0x00000000d5f80000)object space 87552K, 0% used [0x0000000081e00000,0x0000000081ea7990,0x0000000087380000)Metaspace used 3498K, capacity 4498K, committed 4864K, reserved 1056768Kclass space used 387K, capacity 390K, committed 512K, reserved 1048576KProcess finished with exit code 0

1、從打印日志就可以明顯看出來，已經(jīng)進(jìn)行了GC

2、如果使用引用計數(shù)算法，那么這兩個對象將會無法回收。而現(xiàn)在兩個對象被回收了，說明Java使用的不是引用計數(shù)算法來進(jìn)行標(biāo)記的。

小結(jié)

引用計數(shù)算法，是很多語言的資源回收選擇，例如因人工智能而更加火熱的Python，它更是同時支持引用計數(shù)和垃圾收集機(jī)制。

具體哪種最優(yōu)是要看場景的，業(yè)界有大規(guī)模實(shí)踐中僅保留引用計數(shù)機(jī)制，以提高吞吐量的嘗試。

Java并沒有選擇引用計數(shù)，是因?yàn)槠浯嬖谝粋€基本的難題，也就是很難處理循環(huán)引用關(guān)系。

Python如何解決循環(huán)引用？

• 手動解除：很好理解，就是在合適的時機(jī)，解除引用關(guān)系。
• 使用弱引用weakref，weakref是Python提供的標(biāo)準(zhǔn)庫，旨在解決循環(huán)引用。

標(biāo)記階段：可達(dá)性分析算法

可達(dá)性分析算法：也可以稱為根搜索算法、追蹤性垃圾收集

相對于引用計數(shù)算法而言，可達(dá)性分析算法不僅同樣具備實(shí)現(xiàn)簡單和執(zhí)行高效等特點(diǎn)，更重要的是該算法可以有效地解決在引用計數(shù)算法中循環(huán)引用的問題，防止內(nèi)存泄漏的發(fā)生。

相較于引用計數(shù)算法，這里的可達(dá)性分析就是Java、C#選擇的。這種類型的垃圾收集通常也叫作追蹤性垃圾收集（Tracing Garbage Collection）

可達(dá)性分析實(shí)現(xiàn)思路

• 所謂"GCRoots”根集合就是一組必須活躍的引用
• 其基本思路如下：

可達(dá)性分析算法是以根對象集合（GCRoots）為起始點(diǎn)，按照從上至下的方式搜索被根對象集合所連接的目標(biāo)對象是否可達(dá)。

使用可達(dá)性分析算法后，內(nèi)存中的存活對象都會被根對象集合直接或間接連接著，搜索所走過的路徑稱為引用鏈（Reference Chain）

如果目標(biāo)對象沒有任何引用鏈相連，則是不可達(dá)的，就意味著該對象己經(jīng)死亡，可以標(biāo)記為垃圾對象。

在可達(dá)性分析算法中，只有能夠被根對象集合直接或者間接連接的對象才是存活對象。


GC Roots可以是哪些元素？

虛擬機(jī)棧中引用的對象

• 比如：各個線程被調(diào)用的方法中使用到的參數(shù)、局部變量等。

本地方法棧內(nèi)JNI（通常說的本地方法）引用的對象

方法區(qū)中類靜態(tài)屬性引用的對象

• 比如：Java類的引用類型靜態(tài)變量

方法區(qū)中常量引用的對象

• 比如：字符串常量池（StringTable）里的引用

所有被同步鎖synchronized持有的對象

Java虛擬機(jī)內(nèi)部的引用。

• 基本數(shù)據(jù)類型對應(yīng)的Class對象，一些常駐的異常對象（如：NullPointerException、OutofMemoryError），系統(tǒng)類加載器。

反映java虛擬機(jī)內(nèi)部情況的JMXBean、JVMTI中注冊的回調(diào)、本地代碼緩存等。


總結(jié)一句話就是，除了堆空間的周邊，比如：虛擬機(jī)棧、本地方法棧、方法區(qū)、字符串常量池等地方對堆空間進(jìn)行引用的，都可以作為GC Roots進(jìn)行可達(dá)性分析

除了這些固定的GC Roots集合以外，根據(jù)用戶所選用的垃圾收集器以及當(dāng)前回收的內(nèi)存區(qū)域不同，還可以有其他對象“臨時性”地加入，共同構(gòu)成完整GC Roots集合。比如：分代收集和局部回收（PartialGC）。

• 如果只針對Java堆中的某一塊區(qū)域進(jìn)行垃圾回收（比如：典型的只針對新生代），必須考慮到內(nèi)存區(qū)域是虛擬機(jī)自己的實(shí)現(xiàn)細(xì)節(jié)，更不是孤立封閉的，這個區(qū)域的對象完全有可能被其他區(qū)域的對象所引用，這時候就需要一并將關(guān)聯(lián)的區(qū)域?qū)ο笠布尤隚C Roots集合中去考慮，才能保證可達(dá)性分析的準(zhǔn)確性。

小技巧

由于Root采用棧方式存放變量和指針，所以如果一個指針，它保存了堆內(nèi)存里面的對象，但是自己又不存放在堆內(nèi)存里面，那它就是一個Root。

注意

如果要使用可達(dá)性分析算法來判斷內(nèi)存是否可回收，那么分析工作必須在一個能保障一致性的快照中進(jìn)行。這點(diǎn)不滿足的話分析結(jié)果的準(zhǔn)確性就無法保證。

這點(diǎn)也是導(dǎo)致GC進(jìn)行時必須“Stop The World”的一個重要原因。即使是號稱（幾乎）不會發(fā)生停頓的CMS收集器中，枚舉根節(jié)點(diǎn)時也是必須要停頓的。

對象的 finalization 機(jī)制

finalize() 方法機(jī)制

對象銷毀前的回調(diào)函數(shù)：finalize()

Java語言提供了對象終止（finalization）機(jī)制來允許開發(fā)人員提供對象被銷毀之前的自定義處理邏輯。

當(dāng)垃圾回收器發(fā)現(xiàn)沒有引用指向一個對象，即：垃圾回收此對象之前，總會先調(diào)用這個對象的finalize()方法。

finalize() 方法允許在子類中被重寫，用于在對象被回收時進(jìn)行資源釋放。通常在這個方法中進(jìn)行一些資源釋放和清理的工作，比如關(guān)閉文件、套接字和數(shù)據(jù)庫連接等。

Object 類中 finalize() 源碼

// 等待被重寫 protected void finalize() throws Throwable { }

永遠(yuǎn)不要主動調(diào)用某個對象的finalize()方法，應(yīng)該交給垃圾回收機(jī)制調(diào)用。理由包括下面三點(diǎn)：

在finalize()時可能會導(dǎo)致對象復(fù)活。

finalize()方法的執(zhí)行時間是沒有保障的，它完全由GC線程決定，極端情況下，若不發(fā)生GC，則finalize()方法將沒有執(zhí)行機(jī)會。

一個糟糕的finalize()會嚴(yán)重影響GC的性能。比如finalize是個死循環(huán)

從功能上來說，finalize()方法與C中的析構(gòu)函數(shù)比較相似，但是Java采用的是基于垃圾回收器的自動內(nèi)存管理機(jī)制，所以finalize()方法在本質(zhì)上不同于C中的析構(gòu)函數(shù)。

finalize()方法對應(yīng)了一個finalize線程，因?yàn)閮?yōu)先級比較低，即使主動調(diào)用該方法，也不會因此就直接進(jìn)行回收

生存還是死亡？

由于finalize()方法的存在，虛擬機(jī)中的對象一般處于三種可能的狀態(tài)。

如果從所有的根節(jié)點(diǎn)都無法訪問到某個對象，說明對象己經(jīng)不再使用了。一般來說，此對象需要被回收。但事實(shí)上，也并非是“非死不可”的，這時候它們暫時處于“緩刑”階段。一個無法觸及的對象有可能在某一個條件下“復(fù)活”自己，如果這樣，那么對它立即進(jìn)行回收就是不合理的。為此，定義虛擬機(jī)中的對象可能的三種狀態(tài)。如下：

可觸及的：從根節(jié)點(diǎn)開始，可以到達(dá)這個對象。

可復(fù)活的：對象的所有引用都被釋放，但是對象有可能在finalize()中復(fù)活。

不可觸及的：對象的finalize()被調(diào)用，并且沒有復(fù)活，那么就會進(jìn)入不可觸及狀態(tài)。不可觸及的對象不可能被復(fù)活，因?yàn)閒inalize()只會被調(diào)用一次。

以上3種狀態(tài)中，是由于finalize()方法的存在，進(jìn)行的區(qū)分。只有在對象不可觸及時才可以被回收。

具體過程

判定一個對象objA是否可回收，至少要經(jīng)歷兩次標(biāo)記過程：

如果對象objA到GC Roots沒有引用鏈，則進(jìn)行第一次標(biāo)記。

進(jìn)行篩選，判斷此對象是否有必要執(zhí)行finalize()方法

如果對象objA沒有重寫finalize()方法，或者finalize()方法已經(jīng)被虛擬機(jī)調(diào)用過，則虛擬機(jī)視為“沒有必要執(zhí)行”，objA被判定為不可觸及的。

如果對象objA重寫了finalize()方法，且還未執(zhí)行過，那么objA會被插入到F-Queue隊(duì)列中，由一個虛擬機(jī)自動創(chuàng)建的、低優(yōu)先級的Finalizer線程觸發(fā)其finalize()方法執(zhí)行。

finalize()方法是對象逃脫死亡的最后機(jī)會，稍后GC會對F-Queue隊(duì)列中的對象進(jìn)行第二次標(biāo)記。如果objA在finalize()方法中與引用鏈上的任何一個對象建立了聯(lián)系，那么在第二次標(biāo)記時，objA會被移出“即將回收”集合。之后，對象會再次出現(xiàn)沒有引用存在的情況。在這個情況下，finalize()方法不會被再次調(diào)用，對象會直接變成不可觸及的狀態(tài)，也就是說，一個對象的finalize()方法只會被調(diào)用一次。

通過 JVisual VM 查看 Finalizer 線程


代碼演示 finalize() 方法可復(fù)活對象

我們重寫 CanReliveObj 類的 finalize()方法，在調(diào)用其 finalize()方法時，將 obj 指向當(dāng)前類對象 this

/*** 測試Object類中finalize()方法，即對象的finalization機(jī)制。**/ public class CanReliveObj {public static CanReliveObj obj;//類變量，屬于 GC Root//此方法只能被調(diào)用一次@Overrideprotected void finalize() throws Throwable {super.finalize();System.out.println("調(diào)用當(dāng)前類重寫的finalize()方法");obj = this;//當(dāng)前待回收的對象在finalize()方法中與引用鏈上的一個對象obj建立了聯(lián)系}public static void main(String[] args) {try {obj = new CanReliveObj();// 對象第一次成功拯救自己obj = null;System.gc();//調(diào)用垃圾回收器System.out.println("第1次 gc");// 因?yàn)镕inalizer線程優(yōu)先級很低，暫停2秒，以等待它Thread.sleep(2000);if (obj == null) {System.out.println("obj is dead");} else {System.out.println("obj is still alive");}System.out.println("第2次 gc");// 下面這段代碼與上面的完全相同，但是這次自救卻失敗了obj = null;System.gc();// 因?yàn)镕inalizer線程優(yōu)先級很低，暫停2秒，以等待它Thread.sleep(2000);if (obj == null) {System.out.println("obj is dead");} else {System.out.println("obj is still alive");}} catch (InterruptedException e) {e.printStackTrace();}} }

如果注釋掉finalize()方法

//此方法只能被調(diào)用一次@Overrideprotected void finalize() throws Throwable {super.finalize();System.out.println("調(diào)用當(dāng)前類重寫的finalize()方法");obj = this;//當(dāng)前待回收的對象在finalize()方法中與引用鏈上的一個對象obj建立了聯(lián)系}

輸出結(jié)果：

第1次 gc obj is dead 第2次 gc obj is dead

放開finalize()方法

輸出結(jié)果：

第1次 gc 調(diào)用當(dāng)前類重寫的finalize()方法 obj is still alive 第2次 gc obj is dead

第一次自救成功，但由于 finalize() 方法只會執(zhí)行一次，所以第二次自救失敗

MAT與JProfiler的GC Roots溯源

MAT 介紹

MAT是Memory Analyzer的簡稱，它是一款功能強(qiáng)大的Java堆內(nèi)存分析器。用于查找內(nèi)存泄漏以及查看內(nèi)存消耗情況。

MAT是基于Eclipse開發(fā)的，是一款免費(fèi)的性能分析工具。

大家可以在http://www.eclipse.org/mat/下載并使用MAT

1、雖然Jvisualvm很強(qiáng)大，但是在內(nèi)存分析方面，還是MAT更好用一些
2、此小節(jié)主要是為了實(shí)時分析GC Roots是哪些東西，中間需要用到一個dump的文件

獲取 dump 文件方式

方式一：命令行使用 jmap


方式二：使用JVisualVM

捕獲的heap dump文件是一個臨時文件，關(guān)閉JVisualVM后自動刪除，若要保留，需要將其另存為文件。可通過以下方法捕獲heap dump：

操作步驟下面演示

捕捉 dump 示例

使用JVisualVM捕捉 heap dump

代碼：

• numList 和 birth 在第一次捕捉內(nèi)存快照的時候，為 GC Roots
• 之后 numList 和 birth 置為 null ，對應(yīng)的引用對象被回收，在第二次捕捉內(nèi)存快照的時候，就不再是 GC Roots

public class GCRootsTest {public static void main(String[] args) {List<Object> numList = new ArrayList<>();Date birth = new Date();for (int i = 0; i < 100; i++) {numList.add(String.valueOf(i));try {Thread.sleep(10);} catch (InterruptedException e) {e.printStackTrace();}}System.out.println("數(shù)據(jù)添加完畢，請操作：");new Scanner(System.in).next();numList = null;birth = null;System.out.println("numList、birth已置空，請操作：");new Scanner(System.in).next();System.out.println("結(jié)束");} }

如何捕捉堆內(nèi)存快照

1、先執(zhí)行第一步，然后停下來，去生成此步驟dump文件


2、 點(diǎn)擊【堆 Dump】


3、右鍵 --> 另存為即可


4、輸入命令，繼續(xù)執(zhí)行程序


5、我們接著捕獲第二張堆內(nèi)存快照


使用 MAT 查看堆內(nèi)存快照

1、打開 MAT ，選擇File --> Open File，打開剛剛的兩個dump文件，我們先打開第一個dump文件

點(diǎn)擊Open Heap Dump也行


2、選擇Java Basics --> GC Roots


3、第一次捕捉堆內(nèi)存快照時，GC Roots 中包含我們定義的兩個局部變量，類型分別為 ArrayList 和 Date，Total:21


4、打開第二個dump文件，第二次捕獲內(nèi)存快照時，由于兩個局部變量引用的對象被釋放，所以這兩個局部變量不再作為 GC Roots ，從 Total Entries = 19 也可以看出（少了兩個 GC Roots）


JProfiler GC Roots 溯源

1、在實(shí)際開發(fā)中，我們很少會查看所有的GC Roots。一般都是查看某一個或幾個對象的GC Root是哪個，這個過程叫GC Roots 溯源

2、下面我們使用使用 JProfiler 進(jìn)行 GC Roots 溯源演示

依然用下面這個代碼

public class GCRootsTest {public static void main(String[] args) {List<Object> numList = new ArrayList<>();Date birth = new Date();for (int i = 0; i < 100; i++) {numList.add(String.valueOf(i));try {Thread.sleep(10);} catch (InterruptedException e) {e.printStackTrace();}}System.out.println("數(shù)據(jù)添加完畢，請操作：");new Scanner(System.in).next();numList = null;birth = null;System.out.println("numList、birth已置空，請操作：");new Scanner(System.in).next();System.out.println("結(jié)束");} }

1、


2、



可以發(fā)現(xiàn)顏色變綠了，可以動態(tài)的看變化

3、右擊對象，選擇 Show Selection In Heap Walker，單獨(dú)的查看某個對象



4、選擇Incoming References，表示追尋 GC Roots 的源頭

點(diǎn)擊Show Paths To GC Roots，在彈出界面中選擇默認(rèn)設(shè)置即可




JProfiler 分析 OOM

這里是簡單的講一下，后面篇章會詳解

/*** -Xms8m -Xmx8m * -XX:+HeapDumpOnOutOfMemoryError 這個參數(shù)的意思是當(dāng)程序出現(xiàn)OOM的時候就會在當(dāng)前工程目錄生成一個dump文件*/ public class HeapOOM {byte[] buffer = new byte[1 * 1024 * 1024];//1MBpublic static void main(String[] args) {ArrayList<HeapOOM> list = new ArrayList<>();int count = 0;try{while(true){list.add(new HeapOOM());count++;}}catch (Throwable e){System.out.println("count = " + count);e.printStackTrace();}} }

程序輸出日志

com.atguigu.java.HeapOOM java.lang.OutOfMemoryError: Java heap space Dumping heap to java_pid14608.hprof ... java.lang.OutOfMemoryError: Java heap spaceat com.atguigu.java.HeapOOM.<init>(HeapOOM.java:12)at com.atguigu.java.HeapOOM.main(HeapOOM.java:20) Heap dump file created [7797849 bytes in 0.010 secs] count = 6

打開這個dump文件

1、看這個超大對象


2、揪出 main() 線程中出問題的代碼


清除階段：標(biāo)記-清除算法

垃圾清除階段

• 當(dāng)成功區(qū)分出內(nèi)存中存活對象和死亡對象后，GC接下來的任務(wù)就是執(zhí)行垃圾回收，釋放掉無用對象所占用的內(nèi)存空間，以便有足夠的可用內(nèi)存空間為新對象分配內(nèi)存。目前在JVM中比較常見的三種垃圾收集算法是

標(biāo)記-清除算法（Mark-Sweep）

復(fù)制算法（Copying）

標(biāo)記-壓縮算法（Mark-Compact）

背景

標(biāo)記-清除算法（Mark-Sweep）是一種非常基礎(chǔ)和常見的垃圾收集算法，該算法被J.McCarthy等人在1960年提出并并應(yīng)用于Lisp語言。

執(zhí)行過程

當(dāng)堆中的有效內(nèi)存空間（available memory）被耗盡的時候，就會停止整個程序（也被稱為stop the world），然后進(jìn)行兩項(xiàng)工作，第一項(xiàng)則是標(biāo)記，第二項(xiàng)則是清除

標(biāo)記：Collector從引用根節(jié)點(diǎn)開始遍歷，標(biāo)記所有被引用的對象。一般是在對象的Header中記錄為可達(dá)對象。

• 注意：標(biāo)記的是被引用的對象，也就是可達(dá)對象，并非標(biāo)記的是即將被清除的垃圾對象

清除：Collector對堆內(nèi)存從頭到尾進(jìn)行線性的遍歷，如果發(fā)現(xiàn)某個對象在其Header中沒有標(biāo)記為可達(dá)對象，則將其回收


標(biāo)記-清除算法的缺點(diǎn)

標(biāo)記清除算法的效率不算高

在進(jìn)行GC的時候，需要停止整個應(yīng)用程序，用戶體驗(yàn)較差

這種方式清理出來的空閑內(nèi)存是不連續(xù)的，產(chǎn)生內(nèi)碎片，需要維護(hù)一個空閑列表

注意：何為清除？

這里所謂的清除并不是真的置空，而是把需要清除的對象地址保存在空閑的地址列表里。下次有新對象需要加載時，判斷垃圾的位置空間是否夠，如果夠，就存放（也就是覆蓋原有的地址）。

關(guān)于空閑列表是在為對象分配內(nèi)存的時候提過：

如果內(nèi)存規(guī)整

• 采用指針碰撞的方式進(jìn)行內(nèi)存分配

如果內(nèi)存不規(guī)整

• 虛擬機(jī)需要維護(hù)一個空閑列表
• 采用空閑列表分配內(nèi)存

清除階段：復(fù)制算法

背景

為了解決標(biāo)記-清除算法在垃圾收集效率方面的缺陷，M.L.Minsky于1963年發(fā)表了著名的論文，“使用雙存儲區(qū)的Lisp語言垃圾收集器CA LISP Garbage Collector Algorithm Using Serial Secondary Storage）”。M.L.Minsky在該論文中描述的算法被人們稱為復(fù)制（Copying）算法，它也被M.L.Minsky本人成功地引入到了Lisp語言的一個實(shí)現(xiàn)版本中。

核心思想

將活著的內(nèi)存空間分為兩塊，每次只使用其中一塊，在垃圾回收時將正在使用的內(nèi)存中的存活對象復(fù)制到未被使用的內(nèi)存塊中，之后清除正在使用的內(nèi)存塊中的所有對象，交換兩個內(nèi)存的角色，最后完成垃圾回收


新生代里面就用到了復(fù)制算法，Eden區(qū)和S0區(qū)存活對象整體復(fù)制到S1區(qū)

復(fù)制算法的優(yōu)缺點(diǎn)

優(yōu)點(diǎn)

沒有標(biāo)記和清除過程，實(shí)現(xiàn)簡單，運(yùn)行高效

復(fù)制過去以后保證空間的連續(xù)性，不會出現(xiàn)“碎片”問題。

缺點(diǎn)

此算法的缺點(diǎn)也是很明顯的，就是需要兩倍的內(nèi)存空間。

對于G1這種分拆成為大量region的GC，復(fù)制而不是移動，意味著GC需要維護(hù)region之間對象引用關(guān)系，不管是內(nèi)存占用或者時間開銷也不小

復(fù)制算法的應(yīng)用場景

如果系統(tǒng)中的垃圾對象很多，復(fù)制算法需要復(fù)制的存活對象數(shù)量并不會太大，效率較高

老年代大量的對象存活，那么復(fù)制的對象將會有很多，效率會很低

在新生代，對常規(guī)應(yīng)用的垃圾回收，一次通常可以回收70% - 99% 的內(nèi)存空間。回收性價比很高。所以現(xiàn)在的商業(yè)虛擬機(jī)都是用這種收集算法回收新生代。


清除階段：標(biāo)記-壓縮算法

標(biāo)記-壓縮（或標(biāo)記-整理、Mark - Compact）算法

背景

復(fù)制算法的高效性是建立在存活對象少、垃圾對象多的前提下的。這種情況在新生代經(jīng)常發(fā)生，但是在老年代，更常見的情況是大部分對象都是存活對象。如果依然使用復(fù)制算法，由于存活對象較多，復(fù)制的成本也將很高。因此，基于老年代垃圾回收的特性，需要使用其他的算法。

標(biāo)記-清除算法的確可以應(yīng)用在老年代中，但是該算法不僅執(zhí)行效率低下，而且在執(zhí)行完內(nèi)存回收后還會產(chǎn)生內(nèi)存碎片，所以JVM的設(shè)計者需要在此基礎(chǔ)之上進(jìn)行改進(jìn)。標(biāo)記-壓縮（Mark-Compact）算法由此誕生。

1970年前后，G.L.Steele、C.J.Chene和D.s.Wise等研究者發(fā)布標(biāo)記-壓縮算法。在許多現(xiàn)代的垃圾收集器中，人們都使用了標(biāo)記-壓縮算法或其改進(jìn)版本。

執(zhí)行過程

第一階段和標(biāo)記清除算法一樣，從根節(jié)點(diǎn)開始標(biāo)記所有被引用對象

第二階段將所有的存活對象壓縮到內(nèi)存的一端，按順序排放。之后，清理邊界外所有的空間。


標(biāo)記-壓縮算法與標(biāo)記-清除算法的比較

標(biāo)記-壓縮算法的最終效果等同于標(biāo)記-清除算法執(zhí)行完成后，再進(jìn)行一次內(nèi)存碎片整理，因此，也可以把它稱為標(biāo)記-清除-壓縮（Mark-Sweep-Compact）算法。

二者的本質(zhì)差異在于標(biāo)記-清除算法是一種非移動式的回收算法，標(biāo)記-壓縮是移動式的。是否移動回收后的存活對象是一項(xiàng)優(yōu)缺點(diǎn)并存的風(fēng)險決策。

可以看到，標(biāo)記的存活對象將會被整理，按照內(nèi)存地址依次排列，而未被標(biāo)記的內(nèi)存會被清理掉。如此一來，當(dāng)我們需要給新對象分配內(nèi)存時，JVM只需要持有一個內(nèi)存的起始地址即可，這比維護(hù)一個空閑列表顯然少了許多開銷。

標(biāo)記-壓縮算法的優(yōu)缺點(diǎn)

優(yōu)點(diǎn)

消除了標(biāo)記-清除算法當(dāng)中，內(nèi)存區(qū)域分散的缺點(diǎn)，我們需要給新對象分配內(nèi)存時，JVM只需要持有一個內(nèi)存的起始地址即可。

消除了復(fù)制算法當(dāng)中，內(nèi)存減半的高額代價。

缺點(diǎn)

從效率上來說，標(biāo)記-整理算法要低于復(fù)制算法。

移動對象的同時，如果對象被其他對象引用，則還需要調(diào)整引用的地址（因?yàn)镠otSpot虛擬機(jī)采用的不是句柄池的方式，而是直接指針）

移動過程中，需要全程暫停用戶應(yīng)用程序。即：STW

垃圾回收算法小結(jié)

對比三種清除階段的算法

效率上來說，復(fù)制算法是當(dāng)之無愧的老大，但是卻浪費(fèi)了太多內(nèi)存。

而為了盡量兼顧上面提到的三個指標(biāo)，標(biāo)記-整理算法相對來說更平滑一些，但是效率上不盡如人意，它比復(fù)制算法多了一個標(biāo)記的階段，比標(biāo)記-清除多了一個整理內(nèi)存的階段。
| | 標(biāo)記清除 | 標(biāo)記整理 | 復(fù)制 |
| — | — | — | — |
| 速率 | 中等 | 最慢 | 最快 |
| 空間開銷 | 少（但會堆積碎片） | 少（不堆積碎片） | 通常需要活對象的2倍空間（不堆積碎片） |
| 移動對象 | 否 | 是 | 是 |

分代收集算法

Q：難道就沒有一種最優(yōu)的算法嗎？

A：無，沒有最好的算法，只有最合適的算法

為什么要使用分代收集算法

前面所有這些算法中，并沒有一種算法可以完全替代其他算法，它們都具有自己獨(dú)特的優(yōu)勢和特點(diǎn)。分代收集算法應(yīng)運(yùn)而生。

分代收集算法，是基于這樣一個事實(shí)：**不同的對象的生命周期是不一樣的。因此，不同生命周期的對象可以采取不同的收集方式，以便提高回收效率。**一般是把Java堆分為新生代和老年代，這樣就可以根據(jù)各個年代的特點(diǎn)使用不同的回收算法，以提高垃圾回收的效率。

在Java程序運(yùn)行的過程中，會產(chǎn)生大量的對象，其中有些對象是與業(yè)務(wù)信息相關(guān):

• 比如Http請求中的Session對象、線程、Socket連接，這類對象跟業(yè)務(wù)直接掛鉤，因此生命周期比較長。
• 但是還有一些對象，主要是程序運(yùn)行過程中生成的臨時變量，這些對象生命周期會比較短，比如：String對象，由于其不變類的特性，系統(tǒng)會產(chǎn)生大量的這些對象，有些對象甚至只用一次即可回收。

目前幾乎所有的GC都采用分代手機(jī)算法執(zhí)行垃圾回收的

在HotSpot中，基于分代的概念，GC所使用的內(nèi)存回收算法必須結(jié)合年輕代和老年代各自的特點(diǎn)。

年輕代（Young Gen）

• 年輕代特點(diǎn)：區(qū)域相對老年代較小，對象生命周期短、存活率低，回收頻繁。
• 這種情況復(fù)制算法的回收整理，速度是最快的。復(fù)制算法的效率只和當(dāng)前存活對象大小有關(guān)，因此很適用于年輕代的回收。而復(fù)制算法內(nèi)存利用率不高的問題，通過hotspot中的兩個survivor的設(shè)計得到緩解。

老年代（Tenured Gen）

• 老年代特點(diǎn)：區(qū)域較大，對象生命周期長、存活率高，回收不及年輕代頻繁。
• 這種情況存在大量存活率高的對象，復(fù)制算法明顯變得不合適。一般是由標(biāo)記-清除或者是標(biāo)記-清除與標(biāo)記-整理的混合實(shí)現(xiàn)。
  • Mark階段的開銷與存活對象的數(shù)量成正比。
  • Sweep階段的開銷與所管理區(qū)域的大小成正相關(guān)。
  • Compact階段的開銷與存活對象的數(shù)據(jù)成正比。

以HotSpot中的CMS回收器為例，CMS是基于Mark-Sweep實(shí)現(xiàn)的，對于對象的回收效率很高。對于碎片問題，CMS采用基于Mark-Compact算法的Serial Old回收器作為補(bǔ)償措施：當(dāng)內(nèi)存回收不佳（碎片導(dǎo)致的Concurrent Mode Failure時），將采用Serial Old執(zhí)行Full GC以達(dá)到對老年代內(nèi)存的整理。

分代的思想被現(xiàn)有的虛擬機(jī)廣泛使用。幾乎所有的垃圾回收器都區(qū)分新生代和老年代

增量收集算法和分區(qū)算法

增量收集算法

上述現(xiàn)有的算法，在垃圾回收過程中，應(yīng)用軟件將處于一種Stop the World的狀態(tài)。在Stop the World狀態(tài)下，應(yīng)用程序所有的線程都會掛起，暫停一切正常的工作，等待垃圾回收的完成。如果垃圾回收時間過長，應(yīng)用程序會被掛起很久，將嚴(yán)重影響用戶體驗(yàn)或者系統(tǒng)的穩(wěn)定性。為了解決這個問題，即對實(shí)時垃圾收集算法的研究直接導(dǎo)致了增量收集（Incremental Collecting）算法的誕生。

增量收集算法基本思想

如果一次性將所有的垃圾進(jìn)行處理，需要造成系統(tǒng)長時間的停頓，那么就可以讓垃圾收集線程和應(yīng)用程序線程交替執(zhí)行。每次，垃圾收集線程只收集一小片區(qū)域的內(nèi)存空間，接著切換到應(yīng)用程序線程。依次反復(fù)，直到垃圾收集完成。

總的來說，增量收集算法的基礎(chǔ)仍是傳統(tǒng)的標(biāo)記-清除和復(fù)制算法。增量收集算法通過對線程間沖突的妥善處理，允許垃圾收集線程以分階段的方式完成標(biāo)記、清理或復(fù)制工作

增量收集算法的缺點(diǎn)

使用這種方式，由于在垃圾回收過程中，間斷性地還執(zhí)行了應(yīng)用程序代碼，所以能減少系統(tǒng)的停頓時間。但是，因?yàn)榫€程切換和上下文轉(zhuǎn)換的消耗，會使得垃圾回收的總體成本上升，造成系統(tǒng)吞吐量的下降。

分區(qū)算法

主要針對G1收集器來說的

一般來說，在相同條件下，堆空間越大，一次GC時所需要的時間就越長，有關(guān)GC產(chǎn)生的停頓也越長。為了更好地控制GC產(chǎn)生的停頓時間，將一塊大的內(nèi)存區(qū)域分割成多個小塊，根據(jù)目標(biāo)的停頓時間，每次合理地回收若干個小區(qū)間，而不是整個堆空間，從而減少一次GC所產(chǎn)生的停頓。

分代算法將按照對象的生命周期長短劃分成兩個部分，分區(qū)算法將整個堆空間劃分成連續(xù)的不同小區(qū)間。每一個小區(qū)間都獨(dú)立使用，獨(dú)立回收。這種算法的好處是可以控制一次回收多少個小區(qū)間。


寫在最后

注意，這些只是基本的算法思路，實(shí)際GC實(shí)現(xiàn)過程要復(fù)雜的多，目前還在發(fā)展中的前沿GC都是復(fù)合算法，并且并行和并發(fā)兼?zhèn)洹?/p>

總結(jié)

以上是生活随笔為你收集整理的垃圾回收器算法的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。