JVM 垃圾回收

本文導火索

當需要排查各種內存溢出問題、當垃圾收集成爲系統達到更高併發的瓶頸時，我們就需要對這些“自動化”的技術實施必要的監控和調節。

1 揭開 JVM 內存分配與回收的神祕面紗

Java 的自動內存管理主要是針對對象內存的回收和對象內存的分配。同時，Java 自動內存管理最核心的功能是堆內存中對象的分配與回收。上一篇博客中也有提到關於堆在內存區域的介紹。

Java 堆是垃圾收集器管理的主要區域，因此也被稱作GC 堆（Garbage Collected Heap）.從垃圾回收的角度，由於現在收集器基本都採用分代垃圾收集算法，所以 Java 堆還可以細分爲：新生代和老年代：再細緻一點有：Eden 空間、From Survivor、To Survivor 空間等。進一步劃分的目的是更好地回收內存，或者更快地分配內存。

堆空間的基本結構：

上圖所示的

eden 區、s0(“From”) 區、s1(“To”) 區都屬於新生代
tentired 區屬於老年代

大部分情況，對象都會首先在 Eden 區域分配，在一次新生代垃圾回收後，如果對象還存活，則會進入 s1(“To”)，並且對象的年齡還會加 1(Eden 區->Survivor 區後對象的初始年齡變爲 1)，當它的年齡增加到一定程度（默認爲 15 歲），就會被晉升到老年代中。對象晉升到老年代的年齡閾值，可以通過參數 -XX:MaxTenuringThreshold 來設置。經過這次GC後，Eden區和"From"區已經被清空。這個時候，“From"和"To"會交換他們的角色，也就是新的"To"就是上次GC前的“From”，新的"From"就是上次GC前的"To”。不管怎樣，都會保證名爲To的Survivor區域是空的。Minor GC會一直重複這樣的過程，直到“To”區被填滿，"To"區被填滿之後，會將所有對象移動到老年代中。

1.1 對象優先在 eden 區分配

目前主流的垃圾收集器都會採用分代回收算法，因此需要將堆內存分爲新生代和老年代，這樣我們就可以根據各個年代的特點選擇合適的垃圾收集算法。

大多數情況下，對象在新生代中 eden 區分配。當 eden 區沒有足夠空間進行分配時，虛擬機將發起一次 Minor GC.下面我們來進行實際測試以下。

在測試之前我們先來看看 Minor GC 和 Full GC 有什麼不同呢？

新生代 GC（Minor GC）:指發生新生代的的垃圾收集動作，Minor GC 非常頻繁，回收速度一般也比較快。
老年代 GC（Major GC/Full GC）:指發生在老年代的 GC，出現了 Major GC 經常會伴隨至少一次的 Minor GC（並非絕對），Major GC 的速度一般會比 Minor GC 的慢 10 倍以上。

測試：

public class GCTest {

	public static void main(String[] args) {
		byte[] allocation1, allocation2;
		allocation1 = new byte[30900*1024];
		//allocation2 = new byte[900*1024];
	}
}

通過以下方式運行：

添加的參數：-XX:+PrintGCDetails

運行結果 (紅色字體描述有誤，應該是對應於 JDK1.7 的永久代)：

從上圖我們可以看出 eden 區內存幾乎已經被分配完全（即使程序什麼也不做，新生代也會使用 2000 多 k 內存）。假如我們再爲 allocation2 分配內存會出現什麼情況呢？

allocation2 = new byte[900*1024];

簡單解釋一下爲什麼會出現這種情況： 因爲給 allocation2 分配內存的時候 eden 區內存幾乎已經被分配完了，我們剛剛講了當 Eden 區沒有足夠空間進行分配時，虛擬機將發起一次 Minor GC.GC 期間虛擬機又發現 allocation1 無法存入 Survivor 空間，所以只好通過 分配擔保機制 把新生代的對象提前轉移到老年代中去，老年代上的空間足夠存放 allocation1，所以不會出現 Full GC。執行 Minor GC 後，後面分配的對象如果能夠存在 eden 區的話，還是會在 eden 區分配內存。可以執行如下代碼驗證：

public class GCTest {

	public static void main(String[] args) {
		byte[] allocation1, allocation2,allocation3,allocation4,allocation5;
		allocation1 = new byte[32000*1024];
		allocation2 = new byte[1000*1024];
		allocation3 = new byte[1000*1024];
		allocation4 = new byte[1000*1024];
		allocation5 = new byte[1000*1024];
	}
}

1.2 大對象直接進入老年代

大對象就是需要大量連續內存空間的對象（比如：字符串、數組）。

爲什麼要這樣呢？

爲了避免爲大對象分配內存時由於分配擔保機制帶來的複製而降低效率。

1.3 長期存活的對象將進入老年代

既然虛擬機採用了分代收集的思想來管理內存，那麼內存回收時就必須能識別哪些對象應放在新生代，哪些對象應放在老年代中。爲了做到這一點，虛擬機給每個對象一個對象年齡（Age）計數器。

如果對象在 Eden 出生並經過第一次 Minor GC 後仍然能夠存活，並且能被 Survivor 容納的話，將被移動到 Survivor 空間中，並將對象年齡設爲 1.對象在 Survivor 中每熬過一次 MinorGC,年齡就增加 1 歲，當它的年齡增加到一定程度（默認爲 15 歲），就會被晉升到老年代中。對象晉升到老年代的年齡閾值，可以通過參數 -XX:MaxTenuringThreshold 來設置。

1.4 動態對象年齡判定

大部分情況，對象都會首先在 Eden 區域分配，在一次新生代垃圾回收後，如果對象還存活，則會進入 s0 或者 s1，並且對象的年齡還會加 1(Eden 區->Survivor 區後對象的初始年齡變爲 1)，當它的年齡增加到一定程度（默認爲 15 歲），就會被晉升到老年代中。對象晉升到老年代的年齡閾值，可以通過參數 -XX:MaxTenuringThreshold 來設置。

修正“Hotspot遍歷所有對象時，按照年齡從小到大對其所佔用的大小進行累積，當累積的某個年齡大小超過了survivor區的一半時，取這個年齡和MaxTenuringThreshold中更小的一個值，作爲新的晉升年齡閾值”。

動態年齡計算的代碼如下
uint ageTable::compute_tenuring_threshold(size_t survivor_capacity) {
	//survivor_capacity是survivor空間的大小
  size_t desired_survivor_size = (size_t)((((double) survivor_capacity)*TargetSurvivorRatio)/100);
  size_t total = 0;
  uint age = 1;
  while (age < table_size) {
    total += sizes[age];//sizes數組是每個年齡段對象大小
    if (total > desired_survivor_size) break;
    age++;
  }
  uint result = age < MaxTenuringThreshold ? age : MaxTenuringThreshold;
	...
}

2 對象已經死亡？

堆中幾乎放着所有的對象實例，對堆垃圾回收前的第一步就是要判斷那些對象已經死亡（即不能再被任何途徑使用的對象）。

2.1 引用計數法

給對象中添加一個引用計數器，每當有一個地方引用它，計數器就加 1；當引用失效，計數器就減 1；任何時候計數器爲 0 的對象就是不可能再被使用的。

這個方法實現簡單，效率高，但是目前主流的虛擬機中並沒有選擇這個算法來管理內存，其最主要的原因是它很難解決對象之間相互循環引用的問題。 所謂對象之間的相互引用問題，如下面代碼所示：除了對象 objA 和 objB 相互引用着對方之外，這兩個對象之間再無任何引用。但是他們因爲互相引用對方，導致它們的引用計數器都不爲 0，於是引用計數算法無法通知 GC 回收器回收他們。

public class ReferenceCountingGc {
    Object instance = null;
	public static void main(String[] args) {
		ReferenceCountingGc objA = new ReferenceCountingGc();
		ReferenceCountingGc objB = new ReferenceCountingGc();
		objA.instance = objB;
		objB.instance = objA;
		objA = null;
		objB = null;

	}
}

2.2 可達性分析算法

這個算法的基本思想就是通過一系列的稱爲 “GC Roots” 的對象作爲起點，從這些節點開始向下搜索，節點所走過的路徑稱爲引用鏈，當一個對象到 GC Roots 沒有任何引用鏈相連的話，則證明此對象是不可用的。

2.3 再談引用

無論是通過引用計數法判斷對象引用數量，還是通過可達性分析法判斷對象的引用鏈是否可達，判定對象的存活都與“引用”有關。

JDK1.2 之前，Java 中引用的定義很傳統：如果 reference 類型的數據存儲的數值代表的是另一塊內存的起始地址，就稱這塊內存代表一個引用。

JDK1.2 以後，Java 對引用的概念進行了擴充，將引用分爲強引用、軟引用、弱引用、虛引用四種（引用強度逐漸減弱）

1．強引用（StrongReference）

以前我們使用的大部分引用實際上都是強引用，這是使用最普遍的引用。如果一個對象具有強引用，那就類似於必不可少的生活用品，垃圾回收器絕不會回收它。當內存空間不足，Java 虛擬機寧願拋出 OutOfMemoryError 錯誤，使程序異常終止，也不會靠隨意回收具有強引用的對象來解決內存不足問題。

2．軟引用（SoftReference）

如果一個對象只具有軟引用，那就類似於可有可無的生活用品。如果內存空間足夠，垃圾回收器就不會回收它，如果內存空間不足了，就會回收這些對象的內存。只要垃圾回收器沒有回收它，該對象就可以被程序使用。軟引用可用來實現內存敏感的高速緩存。

軟引用可以和一個引用隊列（ReferenceQueue）聯合使用，如果軟引用所引用的對象被垃圾回收，JAVA 虛擬機就會把這個軟引用加入到與之關聯的引用隊列中。

3．弱引用（WeakReference）

如果一個對象只具有弱引用，那就類似於可有可無的生活用品。弱引用與軟引用的區別在於：只具有弱引用的對象擁有更短暫的生命週期。在垃圾回收器線程掃描它所管轄的內存區域的過程中，一旦發現了只具有弱引用的對象，不管當前內存空間足夠與否，都會回收它的內存。不過，由於垃圾回收器是一個優先級很低的線程，因此不一定會很快發現那些只具有弱引用的對象。

弱引用可以和一個引用隊列（ReferenceQueue）聯合使用，如果弱引用所引用的對象被垃圾回收，Java 虛擬機就會把這個弱引用加入到與之關聯的引用隊列中。

4．虛引用（PhantomReference）

"虛引用"顧名思義，就是形同虛設，與其他幾種引用都不同，虛引用並不會決定對象的生命週期。如果一個對象僅持有虛引用，那麼它就和沒有任何引用一樣，在任何時候都可能被垃圾回收。

虛引用主要用來跟蹤對象被垃圾回收的活動。

虛引用與軟引用和弱引用的一個區別在於： 虛引用必須和引用隊列（ReferenceQueue）聯合使用。當垃圾回收器準備回收一個對象時，如果發現它還有虛引用，就會在回收對象的內存之前，把這個虛引用加入到與之關聯的引用隊列中。程序可以通過判斷引用隊列中是否已經加入了虛引用，來了解被引用的對象是否將要被垃圾回收。程序如果發現某個虛引用已經被加入到引用隊列，那麼就可以在所引用的對象的內存被回收之前採取必要的行動。

特別注意，在程序設計中一般很少使用弱引用與虛引用，使用軟引用的情況較多，這是因爲軟引用可以加速 JVM 對垃圾內存的回收速度，可以維護系統的運行安全，防止內存溢出（OutOfMemory）等問題的產生。

2.4 不可達的對象並非“非死不可”

即使在可達性分析法中不可達的對象，也並非是“非死不可”的，這時候它們暫時處於“緩刑階段”，要真正宣告一個對象死亡，至少要經歷兩次標記過程；可達性分析法中不可達的對象被第一次標記並且進行一次篩選，篩選的條件是此對象是否有必要執行 finalize 方法。當對象沒有覆蓋 finalize 方法，或 finalize 方法已經被虛擬機調用過時，虛擬機將這兩種情況視爲沒有必要執行。

被判定爲需要執行的對象將會被放在一個隊列中進行第二次標記，除非這個對象與引用鏈上的任何一個對象建立關聯，否則就會被真的回收。

2.5 如何判斷一個常量是廢棄常量

運行時常量池主要回收的是廢棄的常量。那麼，我們如何判斷一個常量是廢棄常量呢？

假如在常量池中存在字符串 “abc”，如果當前沒有任何 String 對象引用該字符串常量的話，就說明常量 “abc” 就是廢棄常量，如果這時發生內存回收的話而且有必要的話，“abc” 就會被系統清理出常量池。

注意：JDK1.7 及之後版本的 JVM 已經將運行時常量池從方法區中移了出來，在 Java 堆（Heap）中開闢了一塊區域存放運行時常量池。

2.6 如何判斷一個類是無用的類

方法區主要回收的是無用的類，那麼如何判斷一個類是無用的類的呢？

判定一個常量是否是“廢棄常量”比較簡單，而要判定一個類是否是“無用的類”的條件則相對苛刻許多。類需要同時滿足下面 3 個條件才能算是 “無用的類” ：

該類所有的實例都已經被回收，也就是 Java 堆中不存在該類的任何實例。
加載該類的 ClassLoader 已經被回收。
該類對應的 java.lang.Class 對象沒有在任何地方被引用，無法在任何地方通過反射訪問該類的方法。

虛擬機可以對滿足上述 3 個條件的無用類進行回收，這裏說的僅僅是“可以”，而並不是和對象一樣不使用了就會必然被回收。

3 垃圾收集算法

3.1 標記-清除算法

該算法分爲“標記”和“清除”階段：首先標記出所有需要回收的對象，在標記完成後統一回收所有被標記的對象。它是最基礎的收集算法，後續的算法都是對其不足進行改進得到。這種垃圾收集算法會帶來兩個明顯的問題：

效率問題
空間問題（標記清除後會產生大量不連續的碎片）

3.2 複製算法

爲了解決效率問題，“複製”收集算法出現了。它可以將內存分爲大小相同的兩塊，每次使用其中的一塊。當這一塊的內存使用完後，就將還存活的對象複製到另一塊去，然後再把使用的空間一次清理掉。這樣就使每次的內存回收都是對內存區間的一半進行回收。

3.3 標記-整理算法

根據老年代的特點提出的一種標記算法，標記過程仍然與“標記-清除”算法一樣，但後續步驟不是直接對可回收對象回收，而是讓所有存活的對象向一端移動，然後直接清理掉端邊界以外的內存。

3.4 分代收集算法

當前虛擬機的垃圾收集都採用分代收集算法，這種算法沒有什麼新的思想，只是根據對象存活週期的不同將內存分爲幾塊。一般將 java 堆分爲新生代和老年代，這樣我們就可以根據各個年代的特點選擇合適的垃圾收集算法。

比如在新生代中，每次收集都會有大量對象死去，所以可以選擇複製算法，只需要付出少量對象的複製成本就可以完成每次垃圾收集。而老年代的對象存活機率是比較高的，而且沒有額外的空間對它進行分配擔保，所以我們必須選擇“標記-清除”或“標記-整理”算法進行垃圾收集。

延伸面試問題： HotSpot 爲什麼要分爲新生代和老年代？

根據上面的對分代收集算法的介紹回答。

4 垃圾收集器

如果說收集算法是內存回收的方法論，那麼垃圾收集器就是內存回收的具體實現。

雖然我們對各個收集器進行比較，但並非要挑選出一個最好的收集器。因爲直到現在爲止還沒有最好的垃圾收集器出現，更加沒有萬能的垃圾收集器，我們能做的就是根據具體應用場景選擇適合自己的垃圾收集器。試想一下：如果有一種四海之內、任何場景下都適用的完美收集器存在，那麼我們的 HotSpot 虛擬機就不會實現那麼多不同的垃圾收集器了。

4.1 Serial 收集器

Serial（串行）收集器收集器是最基本、歷史最悠久的垃圾收集器了。大家看名字就知道這個收集器是一個單線程收集器了。它的 “單線程” 的意義不僅僅意味着它只會使用一條垃圾收集線程去完成垃圾收集工作，更重要的是它在進行垃圾收集工作的時候必須暫停其他所有的工作線程（ “Stop The World” ），直到它收集結束。

新生代採用複製算法，老年代採用標記-整理算法。

虛擬機的設計者們當然知道 Stop The World 帶來的不良用戶體驗，所以在後續的垃圾收集器設計中停頓時間在不斷縮短（仍然還有停頓，尋找最優秀的垃圾收集器的過程仍然在繼續）。

但是 Serial 收集器有沒有優於其他垃圾收集器的地方呢？當然有，它簡單而高效（與其他收集器的單線程相比）。Serial 收集器由於沒有線程交互的開銷，自然可以獲得很高的單線程收集效率。Serial 收集器對於運行在 Client 模式下的虛擬機來說是個不錯的選擇。

4.2 ParNew 收集器

ParNew 收集器其實就是 Serial 收集器的多線程版本，除了使用多線程進行垃圾收集外，其餘行爲（控制參數、收集算法、回收策略等等）和 Serial 收集器完全一樣。

新生代採用複製算法，老年代採用標記-整理算法。

它是許多運行在 Server 模式下的虛擬機的首要選擇，除了 Serial 收集器外，只有它能與 CMS 收集器（真正意義上的併發收集器，後面會介紹到）配合工作。

並行和併發概念補充：

並行（Parallel） ：指多條垃圾收集線程並行工作，但此時用戶線程仍然處於等待狀態。
併發（Concurrent）：指用戶線程與垃圾收集線程同時執行（但不一定是並行，可能會交替執行），用戶程序在繼續運行，而垃圾收集器運行在另一個 CPU 上。

4.3 Parallel Scavenge 收集器

Parallel Scavenge 收集器也是使用複製算法的多線程收集器，它看上去幾乎和ParNew都一樣。 那麼它有什麼特別之處呢？

-XX:+UseParallelGC 

    使用 Parallel 收集器+ 老年代串行

-XX:+UseParallelOldGC

    使用 Parallel 收集器+ 老年代並行

Parallel Scavenge 收集器關注點是吞吐量（高效率的利用 CPU）。CMS 等垃圾收集器的關注點更多的是用戶線程的停頓時間（提高用戶體驗）。所謂吞吐量就是 CPU 中用於運行用戶代碼的時間與 CPU 總消耗時間的比值。 Parallel Scavenge 收集器提供了很多參數供用戶找到最合適的停頓時間或最大吞吐量，如果對於收集器運作不太瞭解的話，手工優化存在困難的話可以選擇把內存管理優化交給虛擬機去完成也是一個不錯的選擇。

新生代採用複製算法，老年代採用標記-整理算法。

4.4.Serial Old 收集器

Serial 收集器的老年代版本，它同樣是一個單線程收集器。它主要有兩大用途：一種用途是在 JDK1.5 以及以前的版本中與 Parallel Scavenge 收集器搭配使用，另一種用途是作爲 CMS 收集器的後備方案。

4.5 Parallel Old 收集器

Parallel Scavenge 收集器的老年代版本。使用多線程和“標記-整理”算法。在注重吞吐量以及 CPU 資源的場合，都可以優先考慮 Parallel Scavenge 收集器和 Parallel Old 收集器。

4.6 CMS 收集器

CMS（Concurrent Mark Sweep）收集器是一種以獲取最短回收停頓時間爲目標的收集器。它非常符合在注重用戶體驗的應用上使用。

CMS（Concurrent Mark Sweep）收集器是 HotSpot 虛擬機第一款真正意義上的併發收集器，它第一次實現了讓垃圾收集線程與用戶線程（基本上）同時工作。

從名字中的Mark Sweep這兩個詞可以看出，CMS 收集器是一種 “標記-清除”算法實現的，它的運作過程相比於前面幾種垃圾收集器來說更加複雜一些。整個過程分爲四個步驟：

初始標記： 暫停所有的其他線程，並記錄下直接與 root 相連的對象，速度很快；
併發標記： 同時開啓 GC 和用戶線程，用一個閉包結構去記錄可達對象。但在這個階段結束，這個閉包結構並不能保證包含當前所有的可達對象。因爲用戶線程可能會不斷的更新引用域，所以 GC 線程無法保證可達性分析的實時性。所以這個算法裏會跟蹤記錄這些發生引用更新的地方。
重新標記： 重新標記階段就是爲了修正併發標記期間因爲用戶程序繼續運行而導致標記產生變動的那一部分對象的標記記錄，這個階段的停頓時間一般會比初始標記階段的時間稍長，遠遠比並發標記階段時間短
併發清除： 開啓用戶線程，同時 GC 線程開始對爲標記的區域做清掃。

從它的名字就可以看出它是一款優秀的垃圾收集器，主要優點：併發收集、低停頓。但是它有下面三個明顯的缺點：

對 CPU 資源敏感；
無法處理浮動垃圾；
它使用的回收算法-“標記-清除”算法會導致收集結束時會有大量空間碎片產生。

4.7 G1 收集器

G1 (Garbage-First) 是一款面向服務器的垃圾收集器,主要針對配備多顆處理器及大容量內存的機器. 以極高概率滿足 GC 停頓時間要求的同時,還具備高吞吐量性能特徵.

被視爲 JDK1.7 中 HotSpot 虛擬機的一個重要進化特徵。它具備一下特點：

並行與併發：G1 能充分利用 CPU、多核環境下的硬件優勢，使用多個 CPU（CPU 或者 CPU 核心）來縮短 Stop-The-World 停頓時間。部分其他收集器原本需要停頓 Java 線程執行的 GC 動作，G1 收集器仍然可以通過併發的方式讓 java 程序繼續執行。
分代收集：雖然 G1 可以不需要其他收集器配合就能獨立管理整個 GC 堆，但是還是保留了分代的概念。
空間整合：與 CMS 的“標記–清理”算法不同，G1 從整體來看是基於“標記整理”算法實現的收集器；從局部上來看是基於“複製”算法實現的。
可預測的停頓：這是 G1 相對於 CMS 的另一個大優勢，降低停頓時間是 G1 和 CMS 共同的關注點，但 G1 除了追求低停頓外，還能建立可預測的停頓時間模型，能讓使用者明確指定在一個長度爲 M 毫秒的時間片段內。

G1 收集器的運作大致分爲以下幾個步驟：

初始標記
併發標記
最終標記
篩選回收

G1 收集器在後臺維護了一個優先列表，每次根據允許的收集時間，優先選擇回收價值最大的 Region(這也就是它的名字 Garbage-First 的由來)。這種使用 Region 劃分內存空間以及有優先級的區域回收方式，保證了 GF 收集器在有限時間內可以儘可能高的收集效率（把內存化整爲零）。

5. 常見面試題

問題答案在文中都有提到

如何判斷對象是否死亡（兩種方法）。
簡單的介紹一下強引用、軟引用、弱引用、虛引用（虛引用與軟引用和弱引用的區別、使用軟引用能帶來的好處）。
如何判斷一個常量是廢棄常量
如何判斷一個類是無用的類
垃圾收集有哪些算法，各自的特點？
HotSpot 爲什麼要分爲新生代和老年代？
常見的垃圾回收器有哪些？
介紹一下 CMS,G1 收集器。
Minor Gc 和 Full GC 有什麼不同呢？

Ref

《深入理解 Java 虛擬機：JVM 高級特性與最佳實踐（第二版》
https://my.oschina.net/hosee/blog/644618
https://docs.oracle.com/javase/specs/jvms/se8/html/index.html

Java JVM GC 垃圾回收詳細介紹學習筆記

文章目錄

JVM 垃圾回收

本文導火索

1 揭開 JVM 內存分配與回收的神祕面紗

1.1 對象優先在 eden 區分配

1.2 大對象直接進入老年代

1.3 長期存活的對象將進入老年代

1.4 動態對象年齡判定

2 對象已經死亡？

2.1 引用計數法

2.2 可達性分析算法

2.3 再談引用

2.4 不可達的對象並非“非死不可”

2.5 如何判斷一個常量是廢棄常量

2.6 如何判斷一個類是無用的類

3 垃圾收集算法

3.1 標記-清除算法

3.2 複製算法

3.3 標記-整理算法

3.4 分代收集算法

4 垃圾收集器

4.1 Serial 收集器

4.2 ParNew 收集器

4.3 Parallel Scavenge 收集器

4.4.Serial Old 收集器

4.5 Parallel Old 收集器

4.6 CMS 收集器

4.7 G1 收集器

5. 常見面試題

Ref

分佈式系統概念高可用高併發學習筆記

HBase客戶端Write Buffer 介紹及設置

HBASE 技術細節寫入 Region拆分與合併介紹

Kubernetes k8s 基礎架構與設計理念名詞解釋學習筆記

Java 線程調優 JDK常用命令行工具 Jstack & Arthas使用筆記查找耗時線程

Mac下配置sublime實現LaTeX

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結

Java JVM GC 垃圾回收 詳細介紹 學習筆記

文章目錄

JVM 垃圾回收

本文導火索

1 揭開 JVM 內存分配與回收的神祕面紗

1.1 對象優先在 eden 區分配

1.2 大對象直接進入老年代

1.3 長期存活的對象將進入老年代

1.4 動態對象年齡判定

2 對象已經死亡？

2.1 引用計數法

2.2 可達性分析算法

2.3 再談引用

2.4 不可達的對象並非“非死不可”

2.5 如何判斷一個常量是廢棄常量

2.6 如何判斷一個類是無用的類

3 垃圾收集算法

3.1 標記-清除算法

3.2 複製算法

3.3 標記-整理算法

3.4 分代收集算法

4 垃圾收集器

4.1 Serial 收集器

4.2 ParNew 收集器

4.3 Parallel Scavenge 收集器

4.4.Serial Old 收集器

4.5 Parallel Old 收集器

4.6 CMS 收集器

4.7 G1 收集器

5. 常見面試題

Ref

Java JVM GC 垃圾回收詳細介紹學習筆記