開篇

我們知道JVM的垃圾回收機(jī)制實際上是對JVM內(nèi)存的操作，回收的目的是為了避免內(nèi)存溢出和內(nèi)存泄漏的問題。而JVM內(nèi)存由方法區(qū)、堆、虛擬機(jī)棧、本地方法棧以及程序計數(shù)器5塊區(qū)域組成，虛擬機(jī)棧、本地方法棧、程序計數(shù)器是隨著Java線程建立而建立，當(dāng)Java 線程完成之后這三個部分的內(nèi)存就會被釋放掉。

而方法區(qū)和堆屬于共有線程，是隨著JVM啟動而建立的，而且這兩個區(qū)域與另外三個區(qū)域也有所不同，一個接口中有多少個實現(xiàn)類(方法區(qū))以及每次程序運(yùn)行需要創(chuàng)建多少對象(堆)是動態(tài)的，也就是說在程序運(yùn)行時才能知道。

為了讓這部分動態(tài)的內(nèi)存分配能夠進(jìn)行合理的回收，就需要垃圾回收算法和垃圾回收器來幫忙了。下面讓我們進(jìn)入今天的主題。

如何判斷對象“存活”?

JVM 垃圾回收機(jī)制是對堆中沒有使用的對象進(jìn)行回收，那么判斷對象是否“存活”就至關(guān)重要。在判斷對象是否“存活”的方法中，我們會介紹引用計數(shù)算法和可達(dá)性分析法。

引用計數(shù)算法

Java 堆中針對每個對象都設(shè)置一個引用計數(shù)器。當(dāng)一個對象被創(chuàng)建并初始化賦值后，該變量計數(shù)設(shè)置為1。每當(dāng)有一個地方引用它時，計數(shù)器值就加1。當(dāng)引用失效時，即一個對象的某個引用超過了生命周期(出作用域后)或者被設(shè)置為一個新值時，計數(shù)器值就減1。任何引用計數(shù)為0的對象可以被當(dāng)作垃圾回收。當(dāng)一個對象被垃圾回收時，它引用的任何對象計數(shù)減1。

這種方法的優(yōu)點很明顯，引用計數(shù)回收器執(zhí)行簡單，判定效率高，對程序不被長時間打斷的實時環(huán)境比較有利。不過缺點也很明顯，對于對象循環(huán)引用的場景難以判斷，同時引用計數(shù)器增加了程序執(zhí)行的開銷。Java語言并沒有選擇這種算法進(jìn)行垃圾回收。

可達(dá)性分析法

可達(dá)性分析法也叫根搜索算法，通過稱為 GC Roots 的對象作為起點，從上往下進(jìn)行搜索。搜索所走過的路徑稱為引用鏈 (Reference Chain)， 當(dāng)發(fā)現(xiàn)某個對象與 GC Roots之間沒有任何引用鏈相連時, 即認(rèn)為該對象不可達(dá)，該對象也就成了垃圾回收的目標(biāo)。

如圖1 所示，從GC Roots 開始沒有引用鏈和Obejct5、Object6 和Object7 相連，因此這三個對象對于GC Roots 而言就是不可達(dá)的，會被垃圾回收，即便他們互相都有引用。

圖1 可達(dá)性分析法

在Java中，可作為GC Roots的對象包括如下四種：

• 虛擬機(jī)棧(棧幀中的本地變量表)中引用的對象
• 本地方法棧 中 JNI (Native方法)引用的變量
• 方法區(qū) 中類靜態(tài)屬性引用的變量
• 方法區(qū) 中常量引用的變量

前面談到的可達(dá)實際上是在判斷對象是否被引用，如果沒有被引用，垃圾回收器會將其進(jìn)行回收。不過我們希望存在這樣一些對象，當(dāng)內(nèi)存空間足夠的情況下盡量將其保留在內(nèi)存中，當(dāng)內(nèi)存不夠的情況下，再回收這些對象。下面看看如何對如下對象進(jìn)行處理：

• 強(qiáng)引用(Strong Reference)：例如，Object obj = new Object()這類引用，只要強(qiáng)引用存在，垃圾回收器永遠(yuǎn)不會回收掉被引用的對象。
• 軟引用(Soft Reference)：在系統(tǒng)將要出現(xiàn)內(nèi)存溢出之前，會將軟引用對象列進(jìn)回收范圍之中進(jìn)行二次回收。如果這次回收還沒有足夠的內(nèi)存，才會拋出內(nèi)存溢出異常。
• 弱引用(Weak Reference)：被弱引用關(guān)聯(lián)的對象只能生存到下一次垃圾回收發(fā)生之前，無論當(dāng)前內(nèi)存是否足夠，用軟引用相關(guān)聯(lián)的對象都會被回收掉。
• 虛引用(Phantom Reference)：虛引用也稱為幽靈引用或幻影引用，是最弱的一種引用關(guān)系，為一個對象設(shè)置虛引用的唯一目的是：能在這個對象在垃圾回收器回收的時候收到一個系統(tǒng)通知。

垃圾回收算法

上面講解了如何發(fā)現(xiàn)“存活”對象，JVM中會使用可達(dá)性分析法，說白了就是看GC Roots在引用鏈上是否有對應(yīng)的對象被引用到了。接下來就在這個背景下看看有哪些垃圾回收的算法，這里我們列舉出常見的幾種：

標(biāo)記清除算法

該算法分為標(biāo)記和清除兩個階段，首先通過可達(dá)性分析法找到要回收的對象，也就是沒有被引用的對象，對其進(jìn)行標(biāo)記，然后再對該對象進(jìn)行清除也就是回收了。

如圖2 所示，該算法會對內(nèi)存空間進(jìn)行掃描，發(fā)現(xiàn)GC Roots 對Object1 和Object2 進(jìn)行引用，但是對Object2 沒有引用。首先標(biāo)記Object2 沒有被引用。

圖2

如圖3 所示，算法再次對內(nèi)存進(jìn)行掃描，清除Object2 對象占用的空間，將其設(shè)置為空閑空間。

圖3 標(biāo)記清除算法

該算法的優(yōu)點就是簡單粗暴，沒有引用的對象會被清除掉，但是缺點是效率問題。標(biāo)記和清除操作會掃描整個空間兩次(第一次：標(biāo)記存活對象;第二次：清除沒有標(biāo)記的對象)才能完成清理工作。同時清理過程容易產(chǎn)生內(nèi)存碎片，這些空閑的空間無法容納大對象，如果此時有一個比較大的對象進(jìn)入內(nèi)存，由于該內(nèi)存中沒有連續(xù)的容納大對象的空間，就會提前觸發(fā)垃圾回收。

復(fù)制算法

為了解決標(biāo)記清除法帶來的問題，復(fù)制算法將內(nèi)存劃分為大小相等的兩塊，每次使用其中的一塊，當(dāng)這塊的內(nèi)存使用完畢以后，再將對象復(fù)制到另外一塊上面，然后對已經(jīng)使用過的內(nèi)存空間進(jìn)行清理。這樣每次對內(nèi)存的一半?yún)^(qū)域進(jìn)行回收，不用考慮內(nèi)存碎片的問題。

如圖4 所示，上面的區(qū)域是垃圾回收之前的內(nèi)存空間，我們用黑色的虛線將內(nèi)存分為兩個部分。左邊的部分是正在使用的空間，右邊是預(yù)留空間。左邊區(qū)域中紅色的部分是不可回收的內(nèi)存，也就是說這里面有被GC Roots 引用的對象，另外灰色的部分是可回收的區(qū)域，也就是沒有被GC Roots 引用的對象，白色區(qū)域是未分配的。

如果通過復(fù)制算法進(jìn)行垃圾回收，順著綠色的箭頭向下，在回收后的內(nèi)存區(qū)域可以看到，將左側(cè)紅色的內(nèi)存對象移動到了右側(cè)預(yù)留的區(qū)域，并且按照順序排放。然后對左側(cè)運(yùn)行的內(nèi)存區(qū)域進(jìn)行清理，成為預(yù)留區(qū)域等待第二次垃圾回收的執(zhí)行。

圖4 復(fù)制算法

復(fù)制算法的優(yōu)點是簡單高效，不會出現(xiàn)內(nèi)存碎片。缺點也明顯，內(nèi)存利用率低，只有一半的內(nèi)存被利用。特別是存活對象較多時效率明顯降低，因為需要移動每個不可回收數(shù)據(jù)的內(nèi)存實際位置。

標(biāo)記整理算法

該算法和標(biāo)記清除算法相似，但是后續(xù)步驟并不是直接對可回收對象進(jìn)行清理，而是讓所有存活對象都移動到內(nèi)存的前端，然后再清除掉其他可回收的對象所占用的內(nèi)存空間。

如圖5 所示，回收前的內(nèi)存中紅色為不可回收的內(nèi)存空間，灰色是可回收空間，白色是未分配空間。執(zhí)行標(biāo)記整理算法的垃圾回收之后，將不可回收的內(nèi)存空間整理到內(nèi)存的前端，同時清除掉可回收的內(nèi)存空間，此時不可回收空間之后存放的都是白色的未分配空間，供由新對象存放。

圖5 標(biāo)記整理算法

標(biāo)記整理算法優(yōu)點是解決了標(biāo)記清理算法存在的內(nèi)存碎片問題。缺點也是非常明顯，需要進(jìn)行局部對象移動，一定程度上降低了效率。

分代收集算法

分代收集算法，顧名思義是根據(jù)對象的存活周期將內(nèi)存劃分為幾塊，然后定義回收規(guī)則。如圖6所示，從左到右分別是年輕代(Young Generation)、老年代(Old Generation) 和 永久代(Permanent Generation)，另外年輕代又分為了Eden Space(伊甸空間) 、Survivor Space(幸存者空間)。分代收集的算法在當(dāng)前商業(yè)虛擬機(jī)算法中被廣泛采用。

圖6 分代收集法

上面對分代收集法做了字面的解釋，現(xiàn)將該算法的執(zhí)行過程描述如下：

1)新產(chǎn)生的對象優(yōu)先分配在Eden區(qū)(除非配置了-XX:PretenureSizeThreshold，大于該值的對象會直接進(jìn)入老年代)。有這樣一種情況，當(dāng)對象剛剛在新生代創(chuàng)建就被回收了，對象從這個區(qū)域消失的過程我們稱之為 minor GC。

2)當(dāng)Eden區(qū)滿了或放不下了，這時候其中存活的對象會復(fù)制到from區(qū)。如果此時存活下來的對象在from 區(qū)都放不下，就會放到老年代，之后Eden 區(qū)的內(nèi)存會全部回收掉。

3)之后產(chǎn)生的對象繼續(xù)分配在Eden區(qū)，當(dāng)Eden區(qū)又滿了或放不下了，這時候?qū)袳den區(qū)和from區(qū)存活下來的對象復(fù)制到to區(qū)，此時如果存活下來的對象to區(qū)也放不下，會將其移動到年老代，同時會回收掉Eden區(qū)和from區(qū)的內(nèi)存。

4)如果按照如上操作將對象在幾個區(qū)域中移動，會出現(xiàn)對象被多次復(fù)制的情況，對象被復(fù)制一次，對象的年齡就會+1。默認(rèn)情況下，當(dāng)對象被復(fù)制了15次(通過：-XX:MaxTenuringThreshold來配置)，該對象就會進(jìn)入老年代了。

5)當(dāng)老年代滿了的情況下，就會發(fā)生一次Full GC。

備注：Minor GC指發(fā)生在新生代的垃圾收集動作，因為Java對象大多都具備朝生夕滅的特性，所以Minor GC非常頻繁，一般回收速度也比較快。Full GC指發(fā)生在老年代的GC，出現(xiàn)了Full GC，經(jīng)常會伴隨至少一次的Full GC，F(xiàn)ull GC的速度一般會比Minor GC慢10倍以上。

垃圾回收器

如果垃圾回收算法是內(nèi)存回收的方法論的話，那么垃圾回收器就是內(nèi)存回收的具體實現(xiàn)了。下面會針對JDK1.7 Update 14 之后的HotSpot虛擬機(jī)給大家做介紹。

如圖7所示，這里將內(nèi)存分為新生代和老年代，將7種不同垃圾回收器分布于其間，垃圾回收器之間存在連線，說明它們可以搭配使用。

虛擬機(jī)所處的區(qū)域，則表示它是屬于新生代收集器還是老年代收集器。Hotspot實現(xiàn)了如此多的收集器，正是因為目前并無完美的收集器出現(xiàn)，只是選擇對具體應(yīng)用最適合的收集器。

圖7垃圾回收器的分類

下面就來介紹這幾個垃圾回收器：

Serial回收器

Serial(串行)回收器采用復(fù)制算法的新生代收集器，它是一個單線程回收器，針對一個CPU或一條收集線程去完成垃圾收集工作，它在進(jìn)行垃圾收集時，必須暫停其他所有的工作線程，直至Serial收集器收集結(jié)束為止，這個做法也稱為 “Stop The World”。

如圖8 所示，左邊多個應(yīng)用程序線程在執(zhí)行， 當(dāng)Serial 回收器的GC線程(虛線部分)執(zhí)行的時候，應(yīng)用程序線程(左邊多個實線)都會暫停，只有在回收器線程執(zhí)行完畢以后，應(yīng)用程序線程(右邊多個實線)才會繼續(xù)執(zhí)行。

圖 8 串行垃圾回收器

該回收器的問題就是在進(jìn)行垃圾回收時其他工作線程必須停頓，不過它在HotSpot虛擬機(jī)運(yùn)行的Client模式下可以為新生代回收器服務(wù)。它的簡單而高效對于限定單個CPU的環(huán)境來說，Serial回收器沒有線程交互的開銷。在用戶的桌面應(yīng)用場景中，分配給虛擬機(jī)管理的內(nèi)存不大，停頓時間可以控制在幾十毫秒以內(nèi)，還是可以接收。它對于運(yùn)行在Client模式下的虛擬機(jī)來說是一個很好的選擇。

ParNew 回收器

ParNew回收器是Serial回收器的多線程版本，它也是一個新生代回收器。除了使用多線程進(jìn)行垃圾收集外，其余行為包括Serial收集器可用的所有控制參數(shù)、收集算法(復(fù)制算法)、Stop The World、對象分配規(guī)則、回收策略等。

如圖9 所示，與Serial 不同的是ParNew 使用多個線程(中間多條虛線)的方式進(jìn)行垃圾回收。

圖9 ParNew 并行回收器

ParNew 回收器在多CPU環(huán)境下垃圾回收的效率會有明顯提高。它默認(rèn)開啟的收集線程數(shù)與CPU的數(shù)量相同，在CPU非常多的情況下可使用-XX:ParallerGCThreads參數(shù)設(shè)置。反過來，如果針對單個CPU的環(huán)境 ParNew 和Serial 回收器的效果就難分伯仲了。

Serial Old回收器

Serial Old 是 Serial回收器的老年代版本，是單線程收集器，使用標(biāo)記整理(Mark-Compact)算法。它可以給Client模式下的虛擬機(jī)使用。如果在Server模式下，它還有兩大用途：在JDK1.5 以及之前版本(Parallel Old誕生以前)中與Parallel Scavenge收集器搭配使用。作為CMS收集器的后備預(yù)案，在并發(fā)收集發(fā)生Concurrent Mode Failure時使用。

Parallel Old回收器

Parallel Old回收器是Parallel Scavenge的老年代版本，使用多線程的標(biāo)記整理算法。在JDK 1.6中才開始提供，如果新生代選擇了Parallel Scavenge收集器，老年代除了Serial Old以外別無選擇。Parallel Old回收器的工作流程與Parallel Scavenge相同。

Parallel Scavenge 回收器

Parallel Scavenge回收器是并行的多線程新生代回收器，它使用復(fù)制算法。Parallel Scavenge回收器的目標(biāo)是達(dá)到一個可控制的吞吐量(Throughput)。

這里稍微說明一下， 吞吐量就是CPU運(yùn)行用戶代碼時間與CPU總消耗時間的比值，表現(xiàn)成工時是：吞吐量 = 用戶代碼運(yùn)行時間 /(用戶代碼運(yùn)行時間 + 垃圾回收時間)。用戶代碼運(yùn)行時間95 分鐘，垃圾回收時間為5分鐘，那吞吐量就是95/(95+5)=95%。

高吞吐量說明垃圾回收器高效率地利用CPU時間，盡快完成程序的運(yùn)算任務(wù)。從而讓垃圾回收造成的停頓時間變短，適合與用戶交互的程序提升用戶體驗。

Parallel Scavenge會提供精確控制吞吐量的參數(shù)，此外還通過對參數(shù)-XX:+UseAdaptiveSizePolicy 設(shè)置來自動調(diào)節(jié)新生代的大小(-Xmn)、Eden和Survivor區(qū)的比例(-XX:SurvivorRatio)、晉升老年代對象年齡(-XX:PretenureSizeThreshold)等信息。

此外Parallel Scavenge 回收器還有一個特點就是，會根據(jù)當(dāng)前系統(tǒng)的運(yùn)行情況收集性能監(jiān)控信息，動態(tài)調(diào)整這些參數(shù)以提供最合適的停頓時間或者最大的吞吐量，我們稱之為GC自適應(yīng)的調(diào)節(jié)策略(GC Ergonomics)。

CMS收集器

CMS(Concurrent Mark Sweep)收集器是以獲取最短回收停頓時間為目標(biāo)的回收器，它適用于重視響應(yīng)速度的應(yīng)用場景，它是基于標(biāo)記清除算法而實現(xiàn)的。

如圖10 所示，從左往右CMS工作流程分為以下4個步驟：

• 初始標(biāo)記(CMS initial mark)：標(biāo)記GC Roots直接關(guān)聯(lián)到的對象，需要執(zhí)行“Stop The World”，也就是讓工作線程暫停。
• 并發(fā)標(biāo)記(CMS concurrent mark)：從GC Roots 查找所有可達(dá)的對象，這個過程耗時比較長，此時用戶線程依舊在運(yùn)行。
• 重新標(biāo)記(CMS remark)：修正并發(fā)標(biāo)記期間，用戶程序繼續(xù)運(yùn)作而導(dǎo)致標(biāo)記的對象，并且調(diào)整標(biāo)記記錄，此階段也需要“Stop The World”，因為不暫停工作線程的話還可能有標(biāo)記不準(zhǔn)確的情況發(fā)生。
• 并發(fā)清除(CMS concurrent sweep)：對于標(biāo)記不可用的對象進(jìn)行并發(fā)清除操作，這個過程耗時會比較長，此時工作線程依舊可以運(yùn)行。

所以，從總體上來說，CMS收集器的內(nèi)存回收過程是與用戶線程一起并發(fā)執(zhí)行的。通過下圖可以比較清楚地看到CMS收集器的運(yùn)作步驟中并發(fā)和需要停頓的時間：

圖10 CMS 垃圾回收器

CMS的優(yōu)點明顯，并發(fā)收集、低停頓。不過他對CPU資源非常敏感，在并發(fā)階段雖然不會導(dǎo)致用戶線程暫停，但會因為占用了一部分線程(或者說CPU資源)而導(dǎo)致應(yīng)用程序變慢，總吞吐量會降低。

CMS默認(rèn)啟動的回收線程數(shù)是(CPU數(shù)量+3)/4，也就是當(dāng)CPU在4個以上時，并發(fā)回收時垃圾收集線程不少于25%的CPU資源，并且隨著CPU數(shù)量的增加而下降。但是當(dāng)CPU不足4個時(比如2個)，CMS對用戶程序的影響就可能變得很大，如果本來CPU負(fù)載就比較大，還要分出一半的運(yùn)算能力去執(zhí)行收集器線程，就可能導(dǎo)致用戶程序的執(zhí)行速度忽然降低了50%。

無法處理浮動垃圾(Floating Garbage) 可能出現(xiàn)“Concurrent Mode Failure”失敗而導(dǎo)致另一次Full GC的產(chǎn)生。在垃圾回收階段，用戶線程還在運(yùn)行，還需要預(yù)留有足夠的內(nèi)存空間給用戶線程使用，因此CMS需要預(yù)留一部分空間提供并發(fā)收集時的程序運(yùn)作使用。標(biāo)記清除算法本身也會導(dǎo)致產(chǎn)生大量的空間碎片。

G1回收器

G1(Garbage-First)回收器是面向服務(wù)端應(yīng)用的垃圾回收器，它具備如下特點：

• 充分利用多CPU縮短“Stop The World”停頓時間，可以通過并發(fā)的方式讓Java程序繼續(xù)執(zhí)行。
• 不需要其他回收器配合就能獨立管理整個GC堆，采用不同方式去處理新創(chuàng)建的對象和已存活一段時間、對于經(jīng)歷過多次GC的舊對象來說會有更好的回收效果。
• G1基本上是基于標(biāo)記整理算法實現(xiàn)的，在局部(兩個Region之間)是基于復(fù)制算法實現(xiàn)的。這意味著G1運(yùn)行期間不會產(chǎn)生內(nèi)存空間碎片，收集后能提供規(guī)整的可用內(nèi)存。此特性有利于程序長時間運(yùn)行，分配大對象時不會因為無法找到連續(xù)內(nèi)存空間而提前觸發(fā)下一次GC。
• 可預(yù)測的停頓時間模型，能讓使用者明確指定在一個長度為M毫秒的時間片段內(nèi)，消耗在GC上的時間不得超過N毫秒。

與其他垃圾回收器不同的是，G1回收的范圍橫跨整個堆內(nèi)存。

如圖11所示，G1將堆劃分為多個大小相等的區(qū)域(Region)，雖然還保留新生代和老年代的概念，但新生代和老年代不再是物理隔離的了，而是Region的集合。

圖11 G1 將堆進(jìn)行分Region

前面提到G1回收器可以預(yù)測的停頓時間，是因為它避免在整個Java堆中進(jìn)行全區(qū)域的垃圾回收。G1會跟蹤各個Region的垃圾堆積的價值大小(回收的空間大小以及回收所需時間的經(jīng)驗值)，在后臺維護(hù)一個優(yōu)先列表，每次根據(jù)允許的回收時間，優(yōu)先回收價值最大的Region。

雖然G1把Java堆分為多個Region，在某個Region中的對象可以與位于其他Region中的任意對象發(fā)生引用關(guān)系。在做可達(dá)性分析時仍然需要掃描整個堆，顯然這樣做效率是不高的。為了避免全堆掃描， G1為每個Region維護(hù)了一個記憶集(Remembered Set)。當(dāng)發(fā)現(xiàn)程序在對引用(Reference)類型的數(shù)據(jù)進(jìn)行寫操作時，會產(chǎn)生一個Write Barrier暫時中斷寫操作。然后檢查引用(Reference)對象是否處于不同的Region之中，如果是便通過CardTable把相關(guān)引用信息記錄到被引用對象所屬的Region的記憶集(Remembered Set)之中。當(dāng)進(jìn)行內(nèi)存回收時，在GC根節(jié)點的枚舉范圍中加入Remembered Set即可保證不對全堆掃描也不會有遺漏。說白了就是通過Remembered Set 記錄跨Region引用的對象，其目的是避免全堆掃描。

如圖12所示，Region2 中的兩個對象分配被Region1 和Region3 中的對象引用，因此在Region2中的記憶集(Remembered set)就會記錄這兩個引用的信息，在垃圾回收的時候只需要收集記憶集的信息就知道對象在每個Region 的引用關(guān)系了，并不需要掃描所有堆的Region。

圖12 跨Region的對象引用

說了G1 的特點和機(jī)制，下面通過圖13 來看看它的執(zhí)行過程：

• 初始標(biāo)記(Initial Marking)：標(biāo)記GC Roots 能直接引用的對象，讓下一階段用戶程序并發(fā)運(yùn)行時，能在正確的Region中創(chuàng)建對象，此階段需要停頓線程，但耗時很短。
• 并發(fā)標(biāo)記(Concurrent Marking) ：從GC Root 開始對堆中對象進(jìn)行可達(dá)性分析，找到存活對象，此階段耗時較長，但可與用戶程序并發(fā)執(zhí)行。
• 最終標(biāo)記(Final Marking)：為了修正在并發(fā)標(biāo)記期間因用戶程序繼續(xù)運(yùn)作而導(dǎo)致標(biāo)記產(chǎn)生變動的那一部分標(biāo)記記錄，虛擬機(jī)將這段時間對象變化記錄在線程的Remembered Set Logs里面，最終標(biāo)記階段需要把Remembered Set Logs的數(shù)據(jù)合并到Remembered Set中，這階段需要停頓線程，但是可并行執(zhí)行。
• 篩選回收(Live Data Counting and Evacuation) ：首先對各個Region中的回收價值和成本進(jìn)行排序，根據(jù)用戶所期望的GC 停頓時間來制定回收計劃。此階段其實也可以做到與用戶程序一起并發(fā)執(zhí)行，但是因為只回收一部分Region，時間是用戶可控制的，而且停頓用戶線程將大幅度提高收集效率。

總結(jié)

今天給大家介紹了垃圾回收的算法和JVM的垃圾回收器，算法作為思路和方法論的指導(dǎo)，而垃圾回收器是方法論的最佳實踐，這里通過一張表格將兩者進(jìn)行一個總結(jié)：

作者介紹

崔皓，51CTO社區(qū)編輯，資深架構(gòu)師，擁有18年的軟件開發(fā)和架構(gòu)經(jīng)驗，10年分布式架構(gòu)經(jīng)驗。曾任惠普技術(shù)專家。樂于分享，撰寫了很多熱門技術(shù)文章，閱讀量超過60萬。《分布式架構(gòu)原理與實踐》作者。