一文搞懂JAVA与GO垃圾回收
導(dǎo)語 ?現(xiàn)代高級編程語言管理內(nèi)存的方式分為兩種：自動和手動。像 C、C++ 等編程語言使用手動管理內(nèi)存的方式，編寫代碼過程中需要主動申請或者釋放內(nèi)存；而 PHP、Java 和 Go等語言使用自動的內(nèi)存管理系統(tǒng)，由內(nèi)存分配器和垃圾收集器來代為分配和回收內(nèi)存，其中垃圾收集器就是我們常說的GC。本文中，筆者將從原理出發(fā)，介紹Java和Golang垃圾回收算法，并從原理上對他們做一個對比。本文系KM熱門文章，hewitt授權(quán)，發(fā)表在本公眾號上，非常好的文章，分享給大家，值得慢慢細(xì)讀，記得三連支持，感謝。
Java垃圾回收
垃圾回收區(qū)域及劃分
在介紹Java垃圾回收之前，我們需要了解Java的垃圾主要存在于哪個區(qū)域。JVM內(nèi)存運行時區(qū)域劃分如下圖所示：
程序計數(shù)器：是一塊較小的內(nèi)存空間，它可以看作是當(dāng)前線程所執(zhí)行的字節(jié)碼的行號指示器，各條線程之間計數(shù)器互不影響，獨立存儲
虛擬機棧：它描述的是 Java 方法執(zhí)行的內(nèi)存模型：每個方法在執(zhí)行的同時都會創(chuàng)建一個棧幀（Stack Frame，是方法運行時的基礎(chǔ)數(shù)據(jù)結(jié)構(gòu)）用于存儲局部變量表、操作數(shù)棧、動態(tài)鏈接、方法出口等信息。每一個方法從調(diào)用直至執(zhí)行完成的過程，就對應(yīng)著一個棧幀在虛擬機棧中入棧到出棧的過程。
本地方法棧：它與虛擬機棧所發(fā)揮的作用是非常相似的，它們之間的區(qū)別不過是虛擬機棧為虛擬機執(zhí)行 Java 方法（也就是字節(jié)碼）服務(wù)，而本地方法棧則為虛擬機使用到的 Native 方法服務(wù)。
Java 堆：它是 Java 虛擬機所管理的內(nèi)存中最大的一塊。Java 堆是被所有線程共享的一塊內(nèi)存區(qū)域，在虛擬機啟動時創(chuàng)建。此內(nèi)存區(qū)域的唯一目的就是存放對象實例，幾乎所有的對象實例都在這里分配內(nèi)存。
方法區(qū)：它與 Java 堆一樣，是各個線程共享的內(nèi)存區(qū)域，它用于存儲已被虛擬機加載的類信息、常量、靜態(tài)變量、即時編譯器編譯后的代碼等數(shù)據(jù)。
Java內(nèi)存運行時區(qū)域的各個部分，其中程序計數(shù)器、虛擬機棧、本地方法棧3個區(qū)域隨著線程而生，隨著線程而滅；棧中的棧幀隨著方法的進入和退出而有條不紊地執(zhí)行著出棧和入棧的操作，每個棧幀中分配多少內(nèi)存基本是在類結(jié)構(gòu)確定下來時就已知的。而Java堆和方法區(qū)則不同，一個接口中的多個實現(xiàn)類需要的內(nèi)存可能不同，一個方法中的多個分支需要的內(nèi)存也可能不一樣，我們只有在程序處于運行期間時才能知道會創(chuàng)建哪些對象，這部分內(nèi)存的分配和回收都是動態(tài)的，而在java8中，方法區(qū)存放于元空間中，元空間與堆共享物理內(nèi)存，因此，Java堆和方法區(qū)是垃圾收集器管理的主要區(qū)域。
從垃圾回收的角度，由于JVM垃圾收集器基本都采用分代垃圾收集理論，所以 Java 堆還可以細(xì)分為如下幾個區(qū)域（以HotSpot虛擬機默認(rèn)情況為例）：
其中，Eden 區(qū)、From Survivor0(“From”) 區(qū)、To Survivor1(“To”) 區(qū)都屬于新生代，Old Memory 區(qū)屬于老年代。
大部分情況，對象都會首先在 Eden 區(qū)域分配；在一次新生代垃圾回收后，如果對象還存活，則會進入 To 區(qū)，并且對象的年齡還會加 1(Eden 區(qū)->Survivor 區(qū)后對象的初始年齡變?yōu)?1)，當(dāng)它的年齡增加到一定程度（超過了 survivor 區(qū)的一半時，取這個值和 MaxTenuringThreshold中更小的一個值，作為新的晉升年齡閾值），就會晉升到老年代中。經(jīng)過這次 GC 后，Eden 區(qū)和From區(qū)已經(jīng)被清空。這個時候，From和To會交換他們的角色，保證名為 To 的 Survivor 區(qū)域是空的。Minor GC 會一直重復(fù)這樣的過程。在這個過程中，有可能當(dāng)次Minor GC后，Survivor 的"From"區(qū)域空間不夠用，有一些還達不到進入老年代條件的實例放不下，則放不下的部分會提前進入老年代。
針對 HotSpot VM 的實現(xiàn)，它里面的 GC 其實準(zhǔn)確分類只有兩大種：
部分收集 (Partial GC)：
新生代收集（Minor GC / Young GC）：只對新生代進行垃圾收集；
老年代收集（Major GC / Old GC）：只對老年代進行垃圾收集。需要注意的是 Major GC 在有的語境中也用于指代整堆收集；
混合收集（Mixed GC）：對整個新生代和部分老年代進行垃圾收集。
整堆收集 (Full GC)：收集整個 Java 堆和方法區(qū)。
Java堆內(nèi)存常見分配策略
對象優(yōu)先在 eden 區(qū)分配。大部分對象朝生夕滅
大對象直接進入老年代。大對象就是需要大量連續(xù)內(nèi)存空間的對象（比如：字符串、數(shù)組），容易導(dǎo)致內(nèi)存還有不少空間就提前觸發(fā)垃圾收集獲取足夠的連續(xù)空間來安置它們。為了避免為大對象分配內(nèi)存時，由于分配擔(dān)保機制帶來的復(fù)制而降低效率，建議大對象直接進入空間較大的老年代。
長期存活的對象將進入老年代，動態(tài)對象年齡判定：在一次新生代垃圾回收后，如果對象還存活，則會進入 s0 或者 s1，并且對象的年齡還會加 1(Eden 區(qū)->Survivor 區(qū)后對象的初始年齡變?yōu)?1)，當(dāng)它的年齡增加到一定程度（超過了 survivor 區(qū)的一半時，取這個值和 MaxTenuringThreshold中更小的一個值，作為新的晉升年齡閾值），就會被晉升到老年代中。對象晉升到老年代的年齡閾值，可以通過參數(shù) -XX:MaxTenuringThreshold來設(shè)置。
空間分配擔(dān)保。在發(fā)生Minor GC之前，虛擬機會先檢查老年代最大可用連續(xù)內(nèi)存空間是否大于新生代所有對象總空間。如果這個條件成立,那么Minor GC可以確保是安全的。如果不成立，則虛擬機會查看HandlePromotionFailure設(shè)置值是否允許【擔(dān)保失敗】
如果允許，那么會繼續(xù)檢查老年代最大可用的連續(xù)空間是否大于歷次晉升到老年代對象的平均大小
如果大于，將嘗試著進行一次Minor GC，盡管這次Minor GC是有風(fēng)險的
如果小于，或者HandlePromotionFailure設(shè)置不允許冒險，那這時也要改為進行一次Full GC
判斷對象死亡
堆中幾乎放著所有的對象實例，對堆垃圾回收前的第一步就是要判斷哪些對象已經(jīng)死亡（即不能再被任何途徑使用的對象）。判斷一個對象是否存活有引用計數(shù)、可達性分析這兩種算法，兩種算法各有優(yōu)缺點。Java和Go都使用可達性分析算法，一些動態(tài)腳本語言（如:ActionScript）一般使用引用計數(shù)算法。
引用計數(shù)法
給對象中添加一個引用計數(shù)器，每當(dāng)有一個地方引用它，計數(shù)器就加1；當(dāng)引用失效，計數(shù)器就減 1；任何時候計數(shù)器為 0 的對象就是不可能再被使用的。
這個方法實現(xiàn)簡單，效率高，但是目前主流的虛擬機中并沒有選擇這個算法來管理內(nèi)存，其最主要的原因是它很難解決對象之間相互循環(huán)引用的問題。 所謂對象之間的相互引用問題，如下面代碼所示：除了對象 objA 和 objB 相互引用著對方之外，這兩個對象之間再無任何引用。但是他們因為互相引用對方，導(dǎo)致它們的引用計數(shù)器都不為 0，于是引用計數(shù)算法無法通知 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;} }可達性分析算法
這個算法的基本思想就是通過一系列的稱為 “GC Roots” 的對象作為起點，從這些節(jié)點開始向下搜索，節(jié)點所走過的路徑稱為引用鏈，當(dāng)一個對象到 GC Roots 沒有任何引用鏈相連的話，則證明此對象是不可用的。算法優(yōu)點是能準(zhǔn)確標(biāo)識所有的無用對象，包括相互循環(huán)引用的對象；缺點是算法的實現(xiàn)相比引用計數(shù)法復(fù)雜。
不可達的對象并非“非死不可”
即使在可達性分析法中不可達的對象，也并非是“非死不可”的，這時候它們暫時處于“緩刑階段”，要真正宣告一個對象死亡，至少要經(jīng)歷兩次標(biāo)記過程；可達性分析法中不可達的對象被第一次標(biāo)記并且進行一次篩選，篩選的條件是此對象是否有必要執(zhí)行 finalize 方法。當(dāng)對象沒有覆蓋 finalize 方法，或 finalize 方法已經(jīng)被虛擬機調(diào)用過時，虛擬機將這兩種情況視為沒有必要執(zhí)行。被判定為需要執(zhí)行的對象將會被放在一個隊列中進行第二次標(biāo)記，除非這個對象與引用鏈上的任何一個對象建立關(guān)聯(lián)，否則就會被真的回收。
判斷一個運行時常量池中的常量是廢棄常量
JDK1.7 之前運行時常量池邏輯包含字符串常量池存放在方法區(qū), 此時 hotspot 虛擬機對方法區(qū)的實現(xiàn)為永久代
JDK1.7 字符串常量池被從方法區(qū)拿到了堆中, 這里沒有提到運行時常量池,也就是說字符串常量池被單獨拿到堆,運行時常量池剩下的東西還在方法區(qū), 也就是 hotspot 中的永久代 。
JDK1.8 hotspot 移除了永久代用元空間(Metaspace)取而代之, 這時候字符串常量池還在堆, 運行時常量池還在方法區(qū), 只不過方法區(qū)的實現(xiàn)從永久代變成了元空間(Metaspace)
假如在字符串常量池中存在字符串 "abc"，如果當(dāng)前沒有任何 String 對象引用該字符串常量的話，就說明常量 "abc" 就是廢棄常量，如果這時發(fā)生內(nèi)存回收的話而且有必要的話，"abc" 就會被系統(tǒng)清理出常量池了。
如何判斷一個方法區(qū)的類是無用的類
類需要同時滿足下面 3 個條件才能算是 “無用的類”，虛擬機可以對無用類進行回收。
該類所有的實例都已經(jīng)被回收，也就是 Java 堆中不存在該類的任何實例。
加載該類的 ClassLoader 已經(jīng)被回收。
該類對應(yīng)的 java.lang.Class 對象沒有在任何地方被引用，無法在任何地方通過反射訪問該類的方法。
垃圾收集算法
當(dāng)確定了哪些對象可以回收后，就要需要考慮如何對這些對象進行回收，目前垃圾回收算法主要有以下幾種。
標(biāo)記清除算法
該算法分為“標(biāo)記”和“清除”階段：首先標(biāo)記出所有不需要回收的對象，在標(biāo)記完成后統(tǒng)一回收掉所有沒有被標(biāo)記的對象。
適用場合：存活對象較多的情況、適用于年老代（即舊生代）
缺點：
空間問題，容易產(chǎn)生內(nèi)存碎片，再來一個比較大的對象時（典型情況：該對象的大小大于空閑表中的每一塊兒大小但是小于其中兩塊兒的和），會提前觸發(fā)垃圾回收
效率問題，掃描了整個空間兩次（第一次：標(biāo)記存活對象；第二次：清除沒有標(biāo)記的對象）
標(biāo)記復(fù)制算法
為了解決效率問題，“標(biāo)記-復(fù)制”收集算法出現(xiàn)了。它可以將內(nèi)存分為大小相同的兩塊，每次使用其中的一塊。當(dāng)這一塊的內(nèi)存使用完后，就將還存活的對象復(fù)制到另一塊去，然后再把使用的空間一次清理掉。使用復(fù)制算法，回收過程中就不會出現(xiàn)內(nèi)存碎片，也提高了內(nèi)存分配和釋放的效率
適用場合：存活對象較少的情況下比較高效、用于年輕代（即新生代）
缺點：需要一塊兒空的內(nèi)存空間，整理階段，由于移動了可用對象，需要去更新引用。
標(biāo)記整理算法
對于對象存活率較高的場景，復(fù)制算法要進行較多復(fù)制操作，使得效率會變低，這種場景更適合標(biāo)記-整理算法，與標(biāo)記-清理一樣，標(biāo)記整理算法先標(biāo)記出對象的存活狀態(tài)，但在清理時，是先把所有存活對象往一端移動，然后直接清掉邊界以外的內(nèi)存。
適用場合：對象存活率較高（即老年代）
缺點：整理階段，由于移動了可用對象，需要去更新引用。
分代收集算法
當(dāng)前Java虛擬機的垃圾收集都采用分代收集算法，根據(jù)對象存活周期的不同將內(nèi)存分為幾塊。比如在新生代中，每次收集都會有大量對象死去，所以可以選擇”標(biāo)記-復(fù)制“算法，只需要付出少量對象的復(fù)制成本就可以完成每次垃圾收集。而老年代的對象存活幾率是比較高的，而且沒有額外的空間對它進行分配擔(dān)保，所以我們選擇“標(biāo)記-清除”或“標(biāo)記-整理”算法進行垃圾收集。
垃圾收集器
| Serial | 最基本、歷史最悠久的單線程垃圾收集器。 | 新生代采用標(biāo)記-復(fù)制算法，老年代采用標(biāo)記-整理算法。 | 運行在 Client 模式下的虛擬機 | 簡單、高效 | 垃圾回收時必須暫停其他所有的工作線程 |
| ParNew | Serial 收集器的多線程版本 | 新生代采用標(biāo)記-復(fù)制算法，老年代采用標(biāo)記-整理算法 | 運行在 Server 模式下的虛擬機 | 并行，效率高 | |
| Parallel Scavenge | 使用標(biāo)記-復(fù)制算法的多線程收集器，關(guān)注吞吐量 | 新生代采用標(biāo)記-復(fù)制算法，老年代采用標(biāo)記-整理算法。 | JDK1.8 默認(rèn)收集器在注重吞吐量及CPU資源的場合 | 吞吐量高 | |
| Serial Old | Serial 收集器的老年代版本 | 標(biāo)記-整理算法 | 在 JDK<1.5與 Parallel Scavenge 收集器搭配使用作為CMS收集器的后備方案 | 簡單、高效 | 垃圾回收時必須暫停其他所有的工作線程 |
| Parallel Old | Parallel Scavenge 收集器的老年代 | 標(biāo)記-整理算法 | 在注重吞吐量及CPU資源的場合 | 吞吐量高 | |
| CMS | 多線程的垃圾收集器（用戶線程和垃圾回收線程可以同時進行） | 標(biāo)記-清除算法 | 希望系統(tǒng)停頓時間最短，注重服務(wù)的響應(yīng)速度的場景 | 并發(fā)收集、低停頓 | 對 CPU 資源敏感，無法處理浮動垃圾，產(chǎn)生垃圾碎片 |
| G1 | 一款面向服務(wù)器的垃圾收集器，并行并發(fā)，空間整合，可預(yù)測的停頓時間 | 標(biāo)記-復(fù)制算法 | 服務(wù)端應(yīng)用、針對具有大內(nèi)存多處理器的機器 | 停頓時間可控、基本無空間碎片 | 可能存在空間浪費、程序運行時的額外執(zhí)行負(fù)載高 |
雖然我們對各個收集器進行比較，但并非要挑選出一個最好的收集器。因為直到現(xiàn)在為止還沒有最好的垃圾收集器出現(xiàn)，更加沒有萬能的垃圾收集器，我們能做的就是根據(jù)具體應(yīng)用場景選擇適合自己的垃圾收集器。接下來我們將重點介紹CMS垃圾處理器和G1處理器。CMS處理器是和Golang中垃圾回收機制比較類似的一個垃圾處理器，而G1是Java8以來使用最多的垃圾處理器。
CMS 收集器
CMS（Concurrent Mark Sweep）收集器是一種以獲取最短回收停頓時間為目標(biāo)的并發(fā)收集器，也是老年代垃圾收集器，第一次實現(xiàn)了讓垃圾收集線程與用戶線程（基本上）同時工作。CMS收集器在Minor GC時會暫停所有的應(yīng)用線程，并以多線程的方式進行垃圾回收。在Full GC時不再暫停應(yīng)用線程，而是使用若干個后臺線程定期的對老年代空間進行掃描，及時回收其中不再使用的對象。
CMS 收集器是一種 “標(biāo)記-清除”算法實現(xiàn)的，它的運作過程分為7個步驟：
初始標(biāo)記(CMS-initial-mark) ,會導(dǎo)致stw;
并發(fā)標(biāo)記(CMS-concurrent-mark)，與用戶線程同時運行；
預(yù)清理（CMS-concurrent-preclean），與用戶線程同時運行；
可被終止的預(yù)清理（CMS-concurrent-abortable-preclean） 與用戶線程同時運行；
重新標(biāo)記(CMS-remark) ，會導(dǎo)致swt；
并發(fā)清除(CMS-concurrent-sweep)，與用戶線程同時運行；
并發(fā)重置狀態(tài)等待下次CMS的觸發(fā)(CMS-concurrent-reset)，與用戶線程同時運行
初始標(biāo)記（STW）
該階段單線程執(zhí)行，主要分分為兩步：
標(biāo)記GC Roots可達的老年代對象；
遍歷新生代對象，標(biāo)記可達的老年代對象；
該過程結(jié)束后，對象分布如下：
并發(fā)標(biāo)記
該階段GC線程和應(yīng)用線程并發(fā)執(zhí)行，遍歷初始標(biāo)記階段標(biāo)記出來的存活對象，然后繼續(xù)遞歸標(biāo)記這些對象可達的對象。使用三色可達性分析算法進行標(biāo)記，因為該階段并發(fā)執(zhí)行的，在運行期間可能發(fā)生新生代的對象晉升到老年代、或者是直接在老年代分配對象、或者更新老年代對象的引用關(guān)系等等，對于這些對象，都是需要進行重新標(biāo)記的，否則有些對象就會被遺漏，發(fā)生漏標(biāo)的情況。為了提高重新標(biāo)記的效率，該階段會使用三色可達性分析中的增量更新解決這一問題：把上述對象所在的Card標(biāo)識為Dirty，后續(xù)只需掃描這些Dirty Card的對象，避免掃描整個老年代。
預(yù)清理階段
前一個階段已經(jīng)說明，不能標(biāo)記出老年代全部的存活對象，是因為標(biāo)記的同時應(yīng)用程序會改變一些對象引用，這個階段就是用來處理前一個階段因為引用關(guān)系改變導(dǎo)致沒有標(biāo)記到的存活對象的，它會掃描所有標(biāo)記為Dirty的Card 如下圖所示，在并發(fā)清理階段，節(jié)點3的引用指向了6；則會把節(jié)點3的card標(biāo)記為Dirty；
最后將6標(biāo)記為存活,如下圖所示：
可終止的預(yù)處理
這個階段的目標(biāo)跟“預(yù)清理”階段相同，也是為了減輕重新標(biāo)記階段的工作量，。可中斷預(yù)清理的價值：在進入重新標(biāo)記階段之前盡量等到一個Minor GC，盡量縮短重新標(biāo)記階段的停頓時間。另外可中斷預(yù)清理會在Eden達到50%的時候開始，這時候離下一次minor gc還有半程的時間，這個還有另一個意義，即避免短時間內(nèi)連著的兩個停頓。
在該階段，主要循環(huán)的做兩件事：
處理 From 和 To 區(qū)的對象，標(biāo)記可達的老年代對象
和上一個階段一樣，掃描處理Dirty Card中的對象
? ?當(dāng)然了，這個邏輯不會一直循環(huán)下去，打斷這個循環(huán)的條件有三個：
可以設(shè)置最多循環(huán)的次數(shù) CMSMaxAbortablePrecleanLoops，默認(rèn)是0，意思沒有循環(huán)次數(shù)的限制。
如果執(zhí)行這個邏輯的時間達到了閾值CMSMaxAbortablePrecleanTime，默認(rèn)是5s，會退出循環(huán)。
如果新生代Eden區(qū)的內(nèi)存使用率達到了閾值CMSScheduleRemarkEdenPenetration，默認(rèn)50%，會退出循環(huán)。（這個條件能夠成立的前提是，在進行Precleaning時，Eden區(qū)的使用率小于十分之一）
重新標(biāo)記（STW）
這個階段會導(dǎo)致第二次stop the word，該階段的任務(wù)是完成標(biāo)記整個年老代的所有的存活對象。重新掃描堆中的對象，進行可達性分析,標(biāo)記活著的對象。這個階段掃描的目標(biāo)是：新生代的對象 + Gc Roots + 前面被標(biāo)記為dirty的card對應(yīng)的老年代對象。如果預(yù)清理的工作沒做好，這一步掃描新生代的時候就會花很多時間，導(dǎo)致這個階段的停頓時間過長。這個過程是多線程的。
為什么要掃描新生代呢，因為對于老年代中的對象，如果被新生代中的對象引用，那么就會被視為存活對象，即使新生代的對象已經(jīng)不可達了，也會使用這些不可達的對象當(dāng)做cms的“gc root”，來掃描老年代；因此對于老年代來說，引用了老年代中對象的新生代的對象，也會被老年代視作“GC ROOTS”:當(dāng)此階段耗時較長的時候，可以加入?yún)?shù)-XX:+CMSScavengeBeforeRemark，在重新標(biāo)記之前，先執(zhí)行一次ygc，回收掉年輕帶的對象無用的對象，并將對象放入幸存帶或晉升到老年代，這樣再進行年輕帶掃描時，只需要掃描幸存區(qū)的對象即可，一般幸存帶非常小，這大大減少了掃描時間。
并發(fā)清理
通過以上5個階段的標(biāo)記，老年代所有存活的對象已經(jīng)被標(biāo)記并且現(xiàn)在要通過Garbage Collector采用清掃的方式回收那些不能用的對象了。這個階段主要是清除那些沒有標(biāo)記的對象并且回收空間；由于CMS并發(fā)清理階段用戶線程還在運行著，伴隨程序運行自然就還會有新的垃圾不斷產(chǎn)生，這一部分垃圾出現(xiàn)在標(biāo)記過程之后，CMS無法在當(dāng)次收集中處理掉它們，只好留待下一次GC時再清理掉。這一部分垃圾就稱為“浮動垃圾”。
G1 收集器
G1 (Garbage-First) 是一款面向服務(wù)器的垃圾收集器,主要針對配備多顆處理器及大容量內(nèi)存的機器. 以極高概率滿足 GC 停頓時間要求的同時,還具備高吞吐量性能特征.
G1垃圾收集器相對比其他收集器而言，最大的區(qū)別在于它取消了年輕代、老年代的物理劃分，取而代之的是將堆劃分為若干個區(qū)域（Region），這些區(qū)域中包含了有邏輯上的年輕代、老年代區(qū)域。這樣做的好處就是，我們再也不用單獨的空間對每個代進行設(shè)置了，不用擔(dān)心每個代內(nèi)存是否足夠。
它具備一下特點：
并行與并發(fā)：G1 能充分利用 CPU、多核環(huán)境下的硬件優(yōu)勢，使用多個 CPU（CPU 或者 CPU 核心）來縮短 Stop-The-World 停頓時間。部分其他收集器原本需要停頓 Java 線程執(zhí)行的 GC 動作，G1 收集器仍然可以通過并發(fā)的方式讓 java 程序繼續(xù)執(zhí)行。
分代收集：雖然 G1 可以不需要其他收集器配合就能獨立管理整個 GC 堆，但是還是保留了分代的概念。
空間整合：與 CMS 的“標(biāo)記-清理”算法不同，G1 從整體來看是基于“標(biāo)記-整理”算法實現(xiàn)的收集器；從局部上來看是基于“標(biāo)記-復(fù)制”算法實現(xiàn)的。
可預(yù)測的停頓：這是 G1 相對于 CMS 的另一個大優(yōu)勢，降低停頓時間是 G1 和 CMS 共同的關(guān)注點，但 G1 除了追求低停頓外，還能建立可預(yù)測的停頓時間模型，能讓使用者明確指定在一個長度為 M 毫秒的時間片段內(nèi)。
G1算法將堆劃分為若干個區(qū)域（Region），它仍然屬于分代收集器。不過，這些區(qū)域的一部分包含新生代，新生代的垃圾收集依然采用暫停所有應(yīng)用線程的方式，將存活對象拷貝到老年代或者Survivor空間。老年代也分成很多區(qū)域，G1收集器通過將對象從一個區(qū)域復(fù)制到另外一個區(qū)域，完成了清理工作。這就意味著，在正常的處理過程中，G1完成了堆的壓縮（至少是部分堆的壓縮），這樣也就不會有cms內(nèi)存碎片問題的存在了。
對象分配策略，它分為3個階段：
TLAB(Thread Local Allocation Buffer)線程本地分配緩沖區(qū)
Eden區(qū)中分配
Humongous區(qū)分配
TLAB為線程本地分配緩沖區(qū)，它的目的為了使對象盡可能快的分配出來。如果對象在一個共享的空間中分配，我們需要采用一些同步機制來管理這些空間內(nèi)的空閑空間指針。在Eden空間中，每一個線程都有一個固定的分區(qū)用于分配對象，即一個TLAB。分配對象時，線程之間不再需要進行任何的同步。對TLAB空間中無法分配的對象，JVM會嘗試在Eden空間中進行分配。如果Eden空間無法容納該對象，就只能在老年代中進行分配空間。
在G1中，還有一種特殊的區(qū)域，叫Humongous區(qū)域。如果一個對象占用的空間超過了分區(qū)容量50%以上，G1收集器就認(rèn)為這是一個巨型對象。這些巨型對象，默認(rèn)直接會被分配在年老代，但是如果它是一個短期存在的巨型對象，就會對垃圾收集器造成負(fù)面影響。為了解決這個問題，G1劃分了一個Humongous區(qū)，它用來專門存放巨型對象。如果一個H區(qū)裝不下一個巨型對象，那么G1會尋找連續(xù)的H分區(qū)來存儲。為了能找到連續(xù)的H區(qū)，有時候不得不啟動Full GC。
G1 收集器的運作大致分為以下幾個步驟：
初始標(biāo)記
并發(fā)標(biāo)記
最終標(biāo)記
篩選回收
G1 收集器在后臺維護了一個優(yōu)先列表，每次根據(jù)允許的收集時間，優(yōu)先選擇回收價值最大的 Region(這也就是它的名字 Garbage-First 的由來) 。這種使用 Region 劃分內(nèi)存空間以及有優(yōu)先級的區(qū)域回收方式，保證了 G1 收集器在有限時間內(nèi)可以盡可能高的收集效率（把內(nèi)存化整為零）。
關(guān)于G1詳細(xì)原理，可以參考G1收集器的收集原理中的介紹。
Golang垃圾回收
從Go v1.12版本開始，Go使用了非分代的、并發(fā)的、基于三色標(biāo)記和清除的垃圾回收器。和C/C++一樣，Go是一種靜態(tài)類型的編譯型語言。因此，Go不需要VM，Go應(yīng)用程序二進制文件中嵌入了一個小型運行時(Go runtime)，可以處理諸如垃圾收集(GC)，調(diào)度和并發(fā)之類的語言功能。首先讓我們看一下Go內(nèi)部的內(nèi)存管理是什么樣子的
Golang內(nèi)存管理
這里先簡單介紹一下 Golang 運行調(diào)度。在 Golang 里面有三個基本的概念：G, M, P。
G: Goroutine 執(zhí)行的上下文環(huán)境。
M: 操作系統(tǒng)線程。
P: Processer。進程調(diào)度的關(guān)鍵，調(diào)度器，也可以認(rèn)為約等于 CPU。
一個 Goroutine 的運行需要 G + P + M 三部分結(jié)合起來。
TCMalloc
Go將內(nèi)存劃分和分組為頁（Page），這和Java的內(nèi)存結(jié)構(gòu)完全不同，沒有分代內(nèi)存，這樣的原因是Go的內(nèi)存分配器采用了TCMalloc的設(shè)計思想：
Page
與TCMalloc中的Page相同，x64下1個Page的大小是8KB。上圖的最下方，1個淺藍色的長方形代表1個Page。
Span
與TCMalloc中的Span相同，Span是內(nèi)存管理的基本單位，代碼中為mspan，一組連續(xù)的Page組成1個Span，所以上圖一組連續(xù)的淺藍色長方形代表的是一組Page組成的1個Span，另外，1個淡紫色長方形為1個Span。
mcache
mcache是提供給P（邏輯處理器）的高速緩存，用于存儲小對象（對象大小<= 32Kb）。盡管這類似于線程堆棧，但它是堆的一部分，用于動態(tài)數(shù)據(jù)。所有類大小的mcache包含scan和noscan類型mspan。Goroutine可以從mcache沒有任何鎖的情況下獲取內(nèi)存，因為一次P只能有一個鎖G。因此，這更有效。mcache從mcentral需要時請求新的span。
mcentral
mcentral與TCMalloc中的CentralCache類似，是所有線程共享的緩存，需要加鎖訪問，它按Span class對Span分類，串聯(lián)成鏈表，當(dāng)mcache的某個級別Span的內(nèi)存被分配光時，它會向mcentral申請1個當(dāng)前級別的Span。每個mcentral包含兩個mspanList：
empty：雙向span鏈表，包括沒有空閑對象的span或緩存mcache中的span。當(dāng)此處的span被釋放時，它將被移至non-empty span鏈表。
non-empty：有空閑對象的span雙向鏈表。當(dāng)從mcentral請求新的span，mcentral將從該鏈表中獲取span并將其移入empty span鏈表。
mheap
mheap與TCMalloc中的PageHeap類似，它是堆內(nèi)存的抽象，把從OS申請出的內(nèi)存頁組織成Span，并保存起來。當(dāng)mcentral的Span不夠用時會向mheap申請，mheap的Span不夠用時會向OS申請，向OS的內(nèi)存申請是按頁來的，然后把申請來的內(nèi)存頁生成Span組織起來，同樣也是需要加鎖訪問的。
棧
這是棧存儲區(qū)，每個Goroutine（G）有一個棧。在這里存儲了靜態(tài)數(shù)據(jù)，包括函數(shù)棧幀，靜態(tài)結(jié)構(gòu)，原生類型值和指向動態(tài)結(jié)構(gòu)的指針。這與分配給每個P的mcache不是一回事。
內(nèi)存分配
Go中的內(nèi)存分類并不像TCMalloc那樣分成小、中、大對象，但是它的小對象里又細(xì)分了一個Tiny對象，Tiny對象指大小在1Byte到16Byte之間并且不包含指針的對象。小對象和大對象只用大小劃定，無其他區(qū)分。
核心思想：把內(nèi)存分為多級管理，降低鎖的粒度(只是去mcentral和mheap會申請鎖), 以及多種對象大小類型，減少分配產(chǎn)生的內(nèi)存碎片。
微小對象(Tiny)（size <16B）：使用mcache的微小分配器分配小于16個字節(jié)的對象，并且在單個16字節(jié)塊上可完成多個微小分配。
小對象（尺寸16B?32KB）：大小在16個字節(jié)和32k字節(jié)之間的對象被分配在G運行所在的P的mcache的對應(yīng)的mspan size class上。
大對象（大小> 32KB）：大于32 KB的對象直接分配在mheap的相應(yīng)大小類上(size class)。如果mheap為空或沒有足夠大的頁面滿足分配請求，則它將從操作系統(tǒng)中分配一組新的頁（至少1MB）
如果對應(yīng)的大小規(guī)格在 mcache 中沒有可用的塊，則向 mcentral 申請
如果 mcentral 中沒有可用的塊，則向 mheap 申請，并根據(jù) BestFit 算法找到最合適的 mspan。如果申請到的 mspan 超出申請大小，將會根據(jù)需求進行切分，以返回用戶所需的頁數(shù)。剩余的頁構(gòu)成一個新的 mspan 放回 mheap 的空閑列表。
如果 mheap 中沒有可用 span，則向操作系統(tǒng)申請一系列新的頁（最小 1MB）。Go 會在操作系統(tǒng)分配超大的頁（稱作 arena）。分配一大批頁會減少和操作系統(tǒng)通信的成本。
標(biāo)記清除算法
標(biāo)記清除（Mark-Sweep）算法是最常見的垃圾收集算法，標(biāo)記清除收集器是跟蹤式垃圾收集器，其執(zhí)行過程可以分成標(biāo)記（Mark）和清除（Sweep）兩個階段：
標(biāo)記階段 — 從根對象出發(fā)查找并標(biāo)記堆中所有存活的對象；
清除階段 — 遍歷堆中的全部對象，回收未被標(biāo)記的垃圾對象并將回收的內(nèi)存加入空閑鏈表；
如下圖所示，內(nèi)存空間中包含多個對象，我們從根對象出發(fā)依次遍歷對象的子對象并將從根節(jié)點可達的對象都標(biāo)記成存活狀態(tài)，即 A、C 和 D 三個對象，剩余的 B、E 和 F 三個對象因為從根節(jié)點不可達，所以會被當(dāng)做垃圾：
標(biāo)記階段結(jié)束后會進入清除階段，在該階段中收集器會依次遍歷堆中的所有對象，釋放其中沒有被標(biāo)記的 B、E 和 F 三個對象并將新的空閑內(nèi)存空間以鏈表的結(jié)構(gòu)串聯(lián)起來，方便內(nèi)存分配器的使用。
這里介紹的是最傳統(tǒng)的標(biāo)記清除算法，垃圾收集器從垃圾收集的根對象出發(fā)，遞歸遍歷這些對象指向的子對象并將所有可達的對象標(biāo)記成存活；標(biāo)記階段結(jié)束后，垃圾收集器會依次遍歷堆中的對象并清除其中的垃圾，整個過程需要標(biāo)記對象的存活狀態(tài)，用戶程序在垃圾收集的過程中也不能執(zhí)行，我們需要用到更復(fù)雜的機制來解決 STW 的問題。
三色可達性分析
為了解決原始標(biāo)記清除算法帶來的長時間 STW，多數(shù)現(xiàn)代的追蹤式垃圾收集器都會實現(xiàn)三色可達性分析標(biāo)記算法的變種以縮短 STW 的時間。三色可達性分析標(biāo)記算法按“是否被訪問過”將程序中的對象分成白色、黑色和灰色三類：
白色對象 — 潛在的垃圾，其內(nèi)存可能會被垃圾收集器回收；
對象尚未被垃圾收集器訪問過，在可達性分析剛開始的階段，所有的對象都是白色的，若在分析結(jié)束階段，仍然是白色的對象，即代表不可達。
黑色對象 — 活躍的對象，包括不存在任何引用外部指針的對象以及從根對象可達的對象；
表示對象已經(jīng)被垃圾收集器訪問過，且這個對象的所有引用都已經(jīng)被掃描過，黑色的對象代表已經(jīng)被掃描過而且是安全存活的，如果有其他對象只想黑色對象無需再掃描一遍，黑色對象不可能直接（不經(jīng)過灰色對象）指向某個白色對象。
灰色對象 — 活躍的對象，因為存在指向白色對象的外部指針，垃圾收集器會掃描這些對象的子對象；
表示對象已經(jīng)被垃圾收集器訪問過，但是這個對象上至少存在一個引用還沒有被掃描過。
在垃圾收集器開始工作時，程序中不存在任何的黑色對象，垃圾收集的根對象會被標(biāo)記成灰色，垃圾收集器只會從灰色對象集合中取出對象開始掃描，當(dāng)灰色集合中不存在任何對象時，標(biāo)記階段就會結(jié)束。
三色標(biāo)記垃圾收集器的工作原理很簡單，我們可以將其歸納成以下幾個步驟：
從灰色對象的集合中選擇一個灰色對象并將其標(biāo)記成黑色；
將黑色對象指向的所有對象都標(biāo)記成灰色，保證該對象和被該對象引用的對象都不會被回收；
重復(fù)上述兩個步驟直到對象圖中不存在灰色對象；
當(dāng)三色的標(biāo)記清除的標(biāo)記階段結(jié)束之后，應(yīng)用程序的堆中就不存在任何的灰色對象，我們只能看到黑色的存活對象以及白色的垃圾對象，垃圾收集器可以回收這些白色的垃圾，下面是使用三色標(biāo)記垃圾收集器執(zhí)行標(biāo)記后的堆內(nèi)存，堆中只有對象 D 為待回收的垃圾：
因為用戶程序可能在標(biāo)記執(zhí)行的過程中修改對象的指針，所以三色標(biāo)記清除算法本身是不可以并發(fā)或者增量執(zhí)行的，它仍然需要 STW，在如下所示的三色標(biāo)記過程中，用戶程序建立了從 A 對象到 D 對象的引用，但是因為程序中已經(jīng)不存在灰色對象了，所以 D 對象會被垃圾收集器錯誤地回收。本來不應(yīng)該被回收的對象卻被回收了，這在內(nèi)存管理中是非常嚴(yán)重的錯誤，我們將這種錯誤稱為懸掛指針，即指針沒有指向特定類型的合法對象，影響了內(nèi)存的安全性，想要并發(fā)或者增量地標(biāo)記對象還是需要使用屏障技術(shù)。
屏障技術(shù)
內(nèi)存屏障技術(shù)是一種屏障指令，它可以讓 CPU 或者編譯器在執(zhí)行內(nèi)存相關(guān)操作時遵循特定的約束，目前多數(shù)的現(xiàn)代處理器都會亂序執(zhí)行指令以最大化性能，但是該技術(shù)能夠保證內(nèi)存操作的順序性，在內(nèi)存屏障前執(zhí)行的操作一定會先于內(nèi)存屏障后執(zhí)行的操作。
想要在并發(fā)或者增量的標(biāo)記算法中保證正確性，我們需要達成以下兩種三色不變性（Tri-color invariant）中的一種：
強三色不變性 — 黑色對象不會指向白色對象，只會指向灰色對象或者黑色對象；
弱三色不變性 — 黑色對象指向的白色對象必須包含一條從灰色對象經(jīng)由多個白色對象的可達路徑；
上圖分別展示了遵循強三色不變性和弱三色不變性的堆內(nèi)存，遵循上述兩個不變性中的任意一個，我們都能保證垃圾收集算法的正確性，而屏障技術(shù)就是在并發(fā)或者增量標(biāo)記過程中保證三色不變性的重要技術(shù)。
垃圾收集中的屏障技術(shù)更像是一個鉤子方法，它是在用戶程序讀取對象、創(chuàng)建新對象以及更新對象指針時執(zhí)行的一段代碼，根據(jù)操作類型的不同，我們可以將它們分成讀屏障（Read barrier）和寫屏障（Write barrier）兩種，因為讀屏障需要在讀操作中加入代碼片段，對用戶程序的性能影響很大，所以編程語言往往都會采用寫屏障保證三色不變性。
我們在這里想要介紹的是 Go 語言中使用的兩種寫屏障技術(shù)，分別是 Dijkstra 提出的插入寫屏障和 Yuasa 提出的刪除寫屏障，這里會分析它們?nèi)绾伪ＷC三色不變性和垃圾收集器的正確性。
插入寫屏障
Dijkstra 在 1978 年提出了插入寫屏障，通過如下所示的寫屏障，用戶程序和垃圾收集器可以在交替工作的情況下保證程序執(zhí)行的正確性：
func DijkstraWritePointer(slot *unsafe.Pointer, ptr unsafe.Pointer) shade(ptr) ?//先將新下游對象 ptr 標(biāo)記為灰色*slot = ptr }//說明： 添加下游對象(當(dāng)前下游對象slot, 新下游對象ptr) { //step 1標(biāo)記灰色(新下游對象ptr) //step 2當(dāng)前下游對象slot = 新下游對象ptr }//場景： A.添加下游對象(nil, B) //A 之前沒有下游， 新添加一個下游對象B， B被標(biāo)記為灰色 A.添加下游對象(C, B) //A 將下游對象C 更換為B， B被標(biāo)記為灰色上述插入寫屏障的偽代碼非常好理解，每當(dāng)執(zhí)行類似 *slot = ptr 的表達式時，我們會執(zhí)行上述寫屏障通過 shade 函數(shù)嘗試改變指針的顏色。如果 ptr 指針是白色的，那么該函數(shù)會將該對象設(shè)置成灰色，其他情況則保持不變。
假設(shè)我們在應(yīng)用程序中使用 Dijkstra 提出的插入寫屏障，在一個垃圾收集器和用戶程序交替運行的場景中會出現(xiàn)如上圖所示的標(biāo)記過程：
垃圾收集器將根對象指向 A 對象標(biāo)記成黑色并將 A 對象指向的對象 B 標(biāo)記成灰色；
用戶程序修改 A 對象的指針，將原本指向 B 對象的指針指向 C 對象，這時觸發(fā)寫屏障將 C 對象標(biāo)記成灰色；
垃圾收集器依次遍歷程序中的其他灰色對象，將它們分別標(biāo)記成黑色；
Dijkstra 的插入寫屏障是一種相對保守的屏障技術(shù)，它會將有存活可能的對象都標(biāo)記成灰色以滿足強三色不變性。在如上所示的垃圾收集過程中，實際上不再存活的 B 對象最后沒有被回收；而如果我們在第二和第三步之間將指向 C 對象的指針改回指向 B，垃圾收集器仍然認(rèn)為 C 對象是存活的，這些被錯誤標(biāo)記的垃圾對象只有在下一個循環(huán)才會被回收。
插入式的 Dijkstra 寫屏障雖然實現(xiàn)非常簡單并且也能保證強三色不變性，但是它也有明顯的缺點。因為棧上的對象在垃圾收集中也會被認(rèn)為是根對象，所以為了保證內(nèi)存的安全，Dijkstra 必須為棧上的對象增加寫屏障或者在標(biāo)記階段完成重新對棧上的對象進行掃描，這兩種方法各有各的缺點，前者會大幅度增加寫入指針的額外開銷，后者重新掃描棧對象時需要暫停程序，垃圾收集算法的設(shè)計者需要在這兩者之前做出權(quán)衡。
刪除寫屏障
Yuasa 在 1990 年的論文 Real-time garbage collection on general-purpose machines 中提出了刪除寫屏障，因為一旦該寫屏障開始工作，它會保證開啟寫屏障時堆上所有對象的可達，所以也被稱作快照垃圾收集（Snapshot GC）
該算法會使用如下所示的寫屏障保證增量或者并發(fā)執(zhí)行垃圾收集時程序的正確性：
// 黑色賦值器 Yuasa 屏障 func YuasaWritePointer(slot *unsafe.Pointer, ptr unsafe.Pointer) {shade(*slot) 先將*slot標(biāo)記為灰色*slot = ptr }//說明： 添加下游對象(當(dāng)前下游對象slot， 新下游對象ptr) {//step 1if (當(dāng)前下游對象slot是灰色 || 當(dāng)前下游對象slot是白色) {標(biāo)記灰色(當(dāng)前下游對象slot) ? ? //slot為被刪除對象， 標(biāo)記為灰色} ?//step 2當(dāng)前下游對象slot = 新下游對象ptr }//場景 A.添加下游對象(B, nil) ? //A對象，刪除B對象的引用。B被A刪除，被標(biāo)記為灰(如果B之前為白) A.添加下游對象(B, C) ? ? //A對象，更換下游B變成C。B被A刪除，被標(biāo)記為灰(如果B之前為白)上述代碼會在老對象的引用被刪除時，將白色的老對象涂成灰色，這樣刪除寫屏障就可以保證弱三色不變性，老對象引用的下游對象一定可以被灰色對象引用。
假設(shè)我們在應(yīng)用程序中使用 Yuasa 提出的刪除寫屏障，在一個垃圾收集器和用戶程序交替運行的場景中會出現(xiàn)如上圖所示的標(biāo)記過程：
垃圾收集器將根對象指向 A 對象標(biāo)記成黑色并將 A 對象指向的對象 B 標(biāo)記成灰色；
用戶程序?qū)?A 對象原本指向 B 的指針指向 C，觸發(fā)刪除寫屏障，但是因為 B 對象已經(jīng)是灰色的，所以不做改變；
用戶程序?qū)?B 對象原本指向 C 的指針刪除，觸發(fā)刪除寫屏障，白色的 C 對象被涂成灰色；
垃圾收集器依次遍歷程序中的其他灰色對象，將它們分別標(biāo)記成黑色；
上述過程中的第三步觸發(fā)了 Yuasa 刪除寫屏障的著色，因為用戶程序刪除了 B 指向 C 對象的指針，所以 C 和 D 兩個對象會分別違反強三色不變性和弱三色不變性：
強三色不變性 — 黑色的 A 對象直接指向白色的 C 對象；
弱三色不變性 — 垃圾收集器無法從某個灰色對象出發(fā)，經(jīng)過幾個連續(xù)的白色對象訪問白色的 C 和 D 兩個對象；
Yuasa 刪除寫屏障通過對 C 對象的著色，保證了 C 對象和下游的 D 對象能夠在這一次垃圾收集的循環(huán)中存活，避免發(fā)生懸掛指針以保證用戶程序的正確性。
混合寫屏障
在 Go 語言 v1.7 版本之前，運行時會使用 Dijkstra 插入寫屏障保證強三色不變性，但是運行時并沒有在所有的垃圾收集根對象上開啟插入寫屏障。因為應(yīng)用程序可能包含成百上千的 Goroutine，而垃圾收集的根對象一般包括全局變量和棧對象，如果運行時需要在幾百個 Goroutine 的棧上都開啟寫屏障，會帶來巨大的額外開銷，所以 Go 團隊在實現(xiàn)上選擇了在標(biāo)記階段完成時暫停程序、將所有棧對象標(biāo)記為灰色并重新掃描，在活躍 Goroutine 非常多的程序中，重新掃描的過程需要占用 10 ~ 100ms 的時間。
Go 語言在 v1.8 組合 Dijkstra 插入寫屏障和 Yuasa 刪除寫屏障構(gòu)成了如下所示的混合寫屏障，該寫屏障會將被覆蓋的對象標(biāo)記成灰色并在當(dāng)前棧沒有掃描時將新對象也標(biāo)記成灰色：
writePointer(slot, ptr):shade(*slot)if current stack is grey:shade(ptr)*slot = ptr為了移除棧的重掃描過程，除了引入混合寫屏障之外，在垃圾收集的標(biāo)記階段，我們還需要將創(chuàng)建的所有新對象都標(biāo)記成黑色，防止新分配的棧內(nèi)存和堆內(nèi)存中的對象被錯誤地回收，因為棧內(nèi)存在標(biāo)記階段最終都會變?yōu)楹谏?#xff0c;所以不再需要重新掃描棧空間。總結(jié)來說主要有這幾點：
GC 開始將棧上的對象全部掃描并標(biāo)記為黑色；
GC 期間，任何在棧上創(chuàng)建的新對象，均為黑色；
被刪除的堆對象標(biāo)記為灰色；
被添加的堆對象標(biāo)記為灰色；
演進過程
Go 語言的垃圾收集器從誕生的第一天起就一直在演進，除了少數(shù)幾個版本沒有大更新之外，幾乎每次發(fā)布的小版本都會提升垃圾收集的性能，而與性能一同提升的還有垃圾收集器代碼的復(fù)雜度，本節(jié)將從 Go 語言 v1.0 版本開始分析垃圾收集器的演進過程。
v1.0 — 完全串行的標(biāo)記和清除過程，需要暫停整個程序；
v1.1 — 在多核主機并行執(zhí)行垃圾收集的標(biāo)記和清除階段；
v1.3 — 運行時基于只有指針類型的值包含指針的假設(shè)增加了對棧內(nèi)存的精確掃描支持，實現(xiàn)了真正精確的垃圾收集；
將unsafe.Pointer 類型轉(zhuǎn)換成整數(shù)類型的值認(rèn)定為不合法的，可能會造成懸掛指針等嚴(yán)重問題；
v1.5 — 實現(xiàn)了基于三色標(biāo)記清掃的并發(fā)垃圾收集器；
大幅度降低垃圾收集的延遲從幾百 ms 降低至 10ms 以下；
計算垃圾收集啟動的合適時間并通過并發(fā)加速垃圾收集的過程；
v1.6 — 實現(xiàn)了去中心化的垃圾收集協(xié)調(diào)器；
基于顯式的狀態(tài)機使得任意 Goroutine 都能觸發(fā)垃圾收集的狀態(tài)遷移；
使用密集的位圖替代空閑鏈表表示的堆內(nèi)存，降低清除階段的 CPU 占用；
v1.7 — 通過并行棧收縮將垃圾收集的時間縮短至 2ms 以內(nèi)；
v1.8 — 使用混合寫屏障將垃圾收集的時間縮短至 0.5ms 以內(nèi)；
v1.9 — 徹底移除暫停程序的重新掃描棧的過程；
v1.10 — 更新了垃圾收集調(diào)頻器（Pacer）的實現(xiàn)，分離軟硬堆大小的目標(biāo)；
v1.12 — 使用新的標(biāo)記終止算法簡化垃圾收集器的幾個階段；
v1.13 — 通過新的 Scavenger 解決瞬時內(nèi)存占用過高的應(yīng)用程序向操作系統(tǒng)歸還內(nèi)存的問題；
v1.14 — 使用全新的頁分配器優(yōu)化內(nèi)存分配的速度；
v1.15 — 改進編譯器和運行時內(nèi)部的CL 226367，它使編譯器可以將更多的x86寄存器用于垃圾收集器的寫屏障調(diào)用
v1.16 — Go runtime默認(rèn)使用MADV_DONTNEED更積極的將不用的內(nèi)存釋放給OS
GC 過程
Golang GC 相關(guān)的代碼在runtime/mgc.go文件下，可以看見gc總共分為4個階段：
1. sweep termination（清理終止）
? ?a. 暫停程序，觸發(fā)STW。所有的 P（處理器）都會進入 safe-point（安全點）；
? ?b. 清理未被清理的 span 。如果當(dāng)前垃圾收集是強制觸發(fā)的，需要處理還未被清理的內(nèi)存管理單元；
2. the mark phase（標(biāo)記階段）
? ?a. 將GC狀態(tài)gcphase從_GCoff改成_GCmark、開啟寫屏障、啟用協(xié)助線程（mutator assists）、將根對象入隊
? ?b. 恢復(fù)程序執(zhí)行，標(biāo)記進程（mark workers）和協(xié)助程序會開始并發(fā)標(biāo)記內(nèi)存中的對象，寫屏障會覆蓋的重寫指針和新指針（標(biāo)記成灰色），而所有新創(chuàng)建的對象都會被直接標(biāo)記成黑色；
? ?c. GC執(zhí)行根節(jié)點的標(biāo)記，這包括掃描所有的棧、全局對象以及不在堆中的運行時數(shù)據(jù)結(jié)構(gòu)。掃描goroutine 棧會導(dǎo)致 goroutine 停止，并對棧上找到的所有指針加置灰，然后繼續(xù)執(zhí)行 goroutine。
? ?d. GC遍歷灰色對象隊列，會將灰色對象變成黑色，并將該指針指向的對象置灰。
? ?e. 由于GC工作分布在本地緩存中，GC 會使用分布式終止算法（distributed termination algorithm）來檢測何時不再有根標(biāo)記作業(yè)或灰色對象，如果沒有了 GC 會轉(zhuǎn)為mark termination（標(biāo)記終止）
3. mark termination（標(biāo)記終止）
? ?a. STW
? ?b. 將GC狀態(tài)gcphase切換至 _GCmarktermination ，關(guān)閉gc工作線程和協(xié)助程序
? ?c. 執(zhí)行housekeeping，例如刷新mcaches
4. the sweep phase（清理階段）
? ?a. 將GC狀態(tài)gcphase切換至 _GCoff 來準(zhǔn)備清理階段，初始化清理階段并關(guān)閉寫屏障
? ?b. 恢復(fù)用戶程序，從現(xiàn)在開始，所有新創(chuàng)建的對象會標(biāo)記成白色；如果有必要，在使用前分配清理spans
? ?c. 后臺并發(fā)清理所有的內(nèi)存管理類單元
GC過程代碼示例
package mainimport ( "os" "runtime" "runtime/trace" )func gcfinished() *int {p := 1runtime.SetFinalizer(&p, func(_ *int) {println("gc finished") })return &p } func allocate() {_ = make([]byte, int((1<<20)*0.25)) } func main() {f, _ := os.Create("trace.out")defer f.Close()trace.Start(f)defer trace.Stop()gcfinished()// 當(dāng)完成 GC 時停止分配for n := 1; n < 50; n++ {println("#allocate: ", n)allocate() }println("terminate") }運行程序
hewittwang@HEWITTWANG-MB0 rtx % GODEBUG=gctrace=1 go run new1.go ? gc 1 @0.015s 0%: 0.015+0.36+0.043 ms clock, 0.18+0.55/0.64/0.13+0.52 ms? cpu, 4->4->0 MB, 5 MB goal, 12 P gc 2 @0.024s 1%: 0.045+0.19+0.018 ms clock, 0.54+0.37/0.31/0.041+0.22 ms cpu, 4->4->0 MB, 5 MB goal, 12 P ....棧分析
gc 2 : 第一個GC周期 @0.024s : 從程序開始運行到第一次GC時間為0.024 秒 1% : 此次GC過程中CPU 占用率wall clock 0.045+0.19+0.018 ms clock 0.045 ms : STW，Marking Start, 開啟寫屏障 0.19 ms : Marking階段 0.018 ms : STW，Marking終止，關(guān)閉寫屏障CPU time 0.54+0.37/0.31/0.041+0.22 ms cpu 0.54 ms : STW，Marking Start 0.37 ms : 輔助標(biāo)記時間 0.31 ms : 并發(fā)標(biāo)記時間 0.041 ms : GC 空閑時間 0.22 ms : Mark 終止時間4->4->0 MB， 5 MB goal 4 MB ：標(biāo)記開始時，堆大小實際值 4 MB ：標(biāo)記結(jié)束時，堆大小實際值 0 MB ：標(biāo)記結(jié)束時，標(biāo)記為存活對象大小 5 MB ：標(biāo)記結(jié)束時，堆大小預(yù)測值12 P ：本次GC過程中使用的goroutine 數(shù)量GC 觸發(fā)條件
運行時會通過runtime.gcTrigger.test方法決定是否需要觸發(fā)垃圾收集，當(dāng)滿足觸發(fā)垃圾收集的基本條件（即滿足_GCoff階段的退出條件）時 — 允許垃圾收集、程序沒有崩潰并且沒有處于垃圾收集循環(huán)，該方法會根據(jù)三種不同方式觸發(fā)進行不同的檢查：
//mgc.go 文件 runtime.gcTrigger.testfunc (t gcTrigger) test() bool {//測試是否滿足觸發(fā)垃圾手機的基本條件if !memstats.enablegc || panicking != 0 || gcphase != _GCoff {return false}switch t.kind {case gcTriggerHeap: ? ?//堆內(nèi)存的分配達到達控制器計算的觸發(fā)堆大小// Non-atomic access to gcController.heapLive for performance. If// we are going to trigger on this, this thread just// atomically wrote gcController.heapLive anyway and we'll see our// own write.return gcController.heapLive >= gcController.triggercase gcTriggerTime: ? ? ?//如果一定時間內(nèi)沒有觸發(fā)，就會觸發(fā)新的循環(huán)，該出發(fā)條件由 `runtime.forcegcperiod`變量控制，默認(rèn)為 2 分鐘；if gcController.gcPercent < 0 {return false}lastgc := int64(atomic.Load64(&memstats.last_gc_nanotime))return lastgc != 0 && t.now-lastgc > forcegcperiodcase gcTriggerCycle: ? ? ?//如果當(dāng)前沒有開啟垃圾收集，則觸發(fā)新的循環(huán)；// t.n > work.cycles, but accounting for wraparound.return int32(t.n-work.cycles) > 0}return true}用于開啟垃圾回收的方法為runtime.gcStart，因此所有調(diào)用該函數(shù)的地方都是觸發(fā)GC的代碼
runtime.mallocgc 申請內(nèi)存時根據(jù)堆大小觸發(fā)GC
runtime.GC 用戶程序手動觸發(fā)GC
runtime.forcegchelper 后臺運行定時檢查觸發(fā)GC
申請內(nèi)存觸發(fā) runtime.mallocgc
Go運行時會將堆上的對象按大小分成微對象、小對象和大對象三類，這三類對象的創(chuàng)建都可能會觸發(fā)新的GC
當(dāng)前線程的內(nèi)存管理單元中不存在空閑空間時，創(chuàng)建微對象(noscan && size < maxTinySize)和小對象需要調(diào)用 runtime.mcache.nextFree從中心緩存或者頁堆中獲取新的管理單元，這時如果span滿了就會導(dǎo)致返回的shouldhelpgc=true，就可能觸發(fā)垃圾收集；
當(dāng)用戶程序申請分配 32KB 以上的大對象時，一定會構(gòu)建 runtime.gcTrigger結(jié)構(gòu)體嘗試觸發(fā)垃圾收集；
這個時候調(diào)用t.test()執(zhí)行的是gcTriggerHeap情況，只需要判斷gcController.heapLive >= gcController.trigger的真假就可以了。heapLive 表示垃圾收集中存活對象字節(jié)數(shù)， trigger表示觸發(fā)標(biāo)記的堆內(nèi)存大小的；當(dāng)內(nèi)存中存活的對象字節(jié)數(shù)大于觸發(fā)垃圾收集的堆大小時，新一輪的垃圾收集就會開始。
heapLive — 為了減少鎖競爭，運行時只會在中心緩存分配或者釋放內(nèi)存管理單元以及在堆上分配大對象時才會更新；
trigger — 在標(biāo)記終止階段調(diào)用 runtime.gcSetTriggerRatio 更新觸發(fā)下一次垃圾收集的堆大小，它能夠決定觸發(fā)垃圾收集的時間以及用戶程序和后臺處理的標(biāo)記任務(wù)的多少，利用反饋控制的算法根據(jù)堆的增長情況和垃圾收集 CPU 利用率確定觸發(fā)垃圾收集的時機。
手動觸發(fā) runtime.GC
用戶程序會通過 runtime.GC 函數(shù)在程序運行期間主動通知運行時執(zhí)行，該方法在調(diào)用時會阻塞調(diào)用方直到當(dāng)前垃圾收集循環(huán)完成，在垃圾收集期間也可能會通過 STW 暫停整個程序：
func GC() {//在正式開始垃圾收集前，運行時需要通過runtime.gcWaitOnMark等待上一個循環(huán)的標(biāo)記終止、標(biāo)記和清除終止階段完成；n := atomic.Load(&work.cycles)gcWaitOnMark(n)//調(diào)用 `runtime.gcStart` 觸發(fā)新一輪的垃圾收集gcStart(gcTrigger{kind: gcTriggerCycle, n: n + 1})//`runtime.gcWaitOnMark` 等待該輪垃圾收集的標(biāo)記終止階段正常結(jié)束；gcWaitOnMark(n + 1)// 持續(xù)調(diào)用 `runtime.sweepone` 清理全部待處理的內(nèi)存管理單元并等待所有的清理工作完成for atomic.Load(&work.cycles) == n+1 && sweepone() != ^uintptr(0) {sweep.nbgsweep++Gosched() //等待期間會調(diào)用 `runtime.Gosched` 讓出處理器}//for atomic.Load(&work.cycles) == n+1 && !isSweepDone() {Gosched()}// 完成本輪垃圾收集的清理工作后，通過 `runtime.mProf_PostSweep` 將該階段的堆內(nèi)存狀態(tài)快照發(fā)布出來，我們可以獲取這時的內(nèi)存狀態(tài)mp := acquirem()cycle := atomic.Load(&work.cycles)if cycle == n+1 || (gcphase == _GCmark && cycle == n+2) { //僅限于沒有啟動其他標(biāo)記終止過程mProf_PostSweep()}releasem(mp) }后臺運行定時檢查觸發(fā) runtime.forcegchelper
運行時會在應(yīng)用程序啟動時在后臺開啟一個用于強制觸發(fā)垃圾收集的 Goroutine，該 Goroutine調(diào)用 runtime.gcStart 嘗試啟動新一輪的垃圾收集：
// start forcegc helper goroutine func init() {go forcegchelper() }func forcegchelper() {forcegc.g = getg()lockInit(&forcegc.lock, lockRankForcegc)for {lock(&forcegc.lock)if forcegc.idle != 0 {throw("forcegc: phase error")}atomic.Store(&forcegc.idle, 1)//該 Goroutine 會在循環(huán)中調(diào)用runtime.goparkunlock主動陷入休眠等待其他 Goroutine 的喚醒goparkunlock(&forcegc.lock, waitReasonForceGCIdle, traceEvGoBlock, 1)if debug.gctrace > 0 {println("GC forced")}// Time-triggered, fully concurrent.gcStart(gcTrigger{kind: gcTriggerTime, now: nanotime()})} }Java和Go GC對比
垃圾回收區(qū)域
Java內(nèi)存運行時區(qū)域的各個部分，其中程序計數(shù)器、虛擬機棧、本地方法棧3個區(qū)域隨著線程而生，隨著線程而滅；棧中的棧幀隨著方法的進入和退出而有條不紊地執(zhí)行著出棧和入棧的操作，每個棧幀中分配多少內(nèi)存基本是在類結(jié)構(gòu)確定下來時就已知的。而Java堆和方法區(qū)則不同，一個接口中的多個實現(xiàn)類需要的內(nèi)存可能不同，一個方法中的多個分支需要的內(nèi)存也可能不一樣，我們只有在程序處于運行期間時才能知道會創(chuàng)建哪些對象，這部分內(nèi)存的分配和回收都是動態(tài)的，因此，Java堆和方法區(qū)是Java垃圾收集器管理的主要區(qū)域。
go內(nèi)存會分成堆區(qū)（Heap）和棧區(qū)（Stack）兩個部分，程序在運行期間可以主動從堆區(qū)申請內(nèi)存空間，這些內(nèi)存由內(nèi)存分配器分配并由垃圾收集器負(fù)責(zé)回收。棧區(qū)的內(nèi)存由編譯器自動進行分配和釋放，棧區(qū)中存儲著函數(shù)的參數(shù)以及局部變量，它們會隨著函數(shù)的創(chuàng)建而創(chuàng)建，函數(shù)的返回而銷毀。如果只申請和分配內(nèi)存，內(nèi)存終將枯竭。Go使用垃圾回收收集不再使用的span，把span釋放交給mheap，mheap對span進行span的合并，把合并后的span加入scav樹中，等待再分配內(nèi)存時，由mheap進行內(nèi)存再分配。因此，Go堆是Go垃圾收集器管理的主要區(qū)域。
觸發(fā)垃圾回收的時機
Java 當(dāng)應(yīng)用程序空閑時,即沒有應(yīng)用線程在運行時,GC會被調(diào)用。因為GC在優(yōu)先級最低的線程中進行,所以當(dāng)應(yīng)用忙時,GC線程就不會被調(diào)用,但以下條件除外。
Java堆內(nèi)存不足時,GC會被調(diào)用。但是這種情況由于java是分代收集算法且垃圾收集器種類十分多，因此其觸發(fā)各種垃圾收集器的GC時機可能不完全一致，這里我們說的為一般情況。
當(dāng)Eden區(qū)空間不足時Minor GC
對象年齡增加到一定程度時Young GC
新生代對象轉(zhuǎn)入老年代及創(chuàng)建為大對象、大數(shù)組時會導(dǎo)致老年代空間不足，觸發(fā)Old GC
System.gc()調(diào)用觸發(fā)Full GC
各種區(qū)塊占用超過閾值的情況
Go則會根據(jù)以下條件進行觸發(fā)：
runtime.mallocgc 申請內(nèi)存時根據(jù)堆大小觸發(fā)GC
runtime.GC 用戶程序手動觸發(fā)GC
runtime.forcegchelper 后臺運行定時檢查觸發(fā)GC
收集算法
當(dāng)前Java虛擬機的垃圾收集采用分代收集算法，根據(jù)對象存活周期的不同將內(nèi)存分為幾塊。比如在新生代中，每次收集都會有大量對象死去，所以可以選擇“標(biāo)記-復(fù)制”算法，只需要付出少量對象的復(fù)制成本就可以完成每次垃圾收集。而老年代的對象存活幾率是比較高的，而且沒有額外的空間對它進行分配擔(dān)保，所以我們必須選擇“標(biāo)記-清除”或“標(biāo)記-整理”算法進行垃圾收集。
當(dāng)前Go的都是基于標(biāo)記清除算法進行垃圾回收。
垃圾碎片的處理
由于Java的內(nèi)存管理劃分，因此容易產(chǎn)生垃圾對象，JVM這些年不斷的改進和更新GC算法，JVM在處理內(nèi)存碎片問題上更多采用空間壓縮和分代收集的思想，例如在新生代使用“標(biāo)記-復(fù)制”算法，G1收集器支持了對象移動以消減長時間運行的內(nèi)存碎片問題，劃分region的設(shè)計更容易把空閑內(nèi)存歸還給OS等設(shè)計。
由于Go的內(nèi)存管理的實現(xiàn)，很難實現(xiàn)分代，而移動對象也可能會導(dǎo)致runtime更龐大復(fù)雜，因此Go在關(guān)于內(nèi)存碎片的處理方案和Java并不太一樣。
1. Go語言span內(nèi)存池的設(shè)計，減輕了很多內(nèi)存碎片的問題。
Go內(nèi)存釋放的過程如下：當(dāng) mcache 中存在較多空閑 span 時，會歸還給 mcentral；而 mcentral 中存在較多空閑 span 時，會歸還給 mheap；mheap 再歸還給操作系統(tǒng)。這種設(shè)計主要有以下幾個優(yōu)勢：
內(nèi)存分配大多時候都是在用戶態(tài)完成的，不需要頻繁進入內(nèi)核態(tài)。
每個 P 都有獨立的 span cache，多個 CPU 不會并發(fā)讀寫同一塊內(nèi)存，進而減少 CPU L1 cache 的 cacheline 出現(xiàn) dirty 情況，增大 cpu cache 命中率。
內(nèi)存碎片的問題，Go 是自己在用戶態(tài)管理的，在 OS 層面看是沒有碎片的，使得操作系統(tǒng)層面對碎片的管理壓力也會降低。
mcache 的存在使得內(nèi)存分配不需要加鎖。
2. tcmalloc分配機制，Tiny對象和大對象分配優(yōu)化，在某種程度上也導(dǎo)致基本沒有內(nèi)存碎片會出現(xiàn)。
比如常規(guī)上 sizeclass=1的 span，用來給 <= 8B 的對象使用，所以像 int32, byte, bool 以及小字符串等常用的微小對象，都會使用 sizeclass=1 的 span，但分配給他們 8B 的空間，大部分是用不上的。并且這些類型使用頻率非常高，就會導(dǎo)致出現(xiàn)大量的內(nèi)部碎片。
因此 Go 盡量不使用 sizeclass=1 的 span， 而是將 < 16B 的對象為統(tǒng)一視為 tiny 對象。分配時，從 sizeclass=2 的 span 中獲取一個 16B 的 object 用以分配。如果存儲的對象小于 16B，這個空間會被暫時保存起來 (mcache.tiny 字段)，下次分配時會復(fù)用這個空間，直到這個 object 用完為止。
以上圖為例，這樣的方式空間利用率是 (1+2+8) / 16 * 100% = 68.75%，而如果按照原始的管理方式，利用率是 (1+2+8) / (8 * 3) = 45.83%。源碼中注釋描述，說是對 tiny 對象的特殊處理，平均會節(jié)省 20% 左右的內(nèi)存。如果要存儲的數(shù)據(jù)里有指針，即使 <= 8B 也不會作為 tiny 對象對待，而是正常使用 sizeclass=1 的 span。
Go中，最大的 sizeclass 最大只能存放 32K 的對象。如果一次性申請超過 32K 的內(nèi)存，系統(tǒng)會直接繞過 mcache 和 mcentral，直接從 mheap 上獲取，mheap 中有一個 freelarge 字段管理著超大 span。
3. Go的對象(即struct類型)是可以分配在棧上的。
Go會在編譯時做靜態(tài)逃逸分析(Escape Analysis), 如果發(fā)現(xiàn)某個對象并沒有逃出當(dāng)前作用域，則會將對象分配在棧上而不是堆上，從而減輕了GC內(nèi)存碎片回收壓力。
比如如下代碼
func F() {temp := make([]int, 0, 20) //只是內(nèi)函數(shù)內(nèi)部申請的臨時變量，并不會作為返回值返回，它就是被編譯器申請到棧里面。temp = append(temp, 1) }func main() {F() }運行代碼如下，結(jié)果顯示temp變量被分配在棧上并沒有分配在堆上
當(dāng)我們把上述代碼更改：
運行代碼如下，結(jié)果顯示temp變量被分配在堆上，這是由于temp傳入了print函數(shù)里，編譯器會認(rèn)為變量之后還會被使用。因此就申請到堆上，申請到堆上面的內(nèi)存才會引起垃圾回收，如果這個過程（特指垃圾回收不斷被觸發(fā)）過于高頻就會導(dǎo)致 gc 壓力過大，程序性能出問題。
“GC Roots” 的對象的選擇
在Java中由于內(nèi)存運行時區(qū)域的劃分，通常會選擇以下幾種作為“GC Roots” 的對象：
虛擬機棧(棧幀中的本地變量表)中引用的對象
本地方法棧(Native 方法)中引用的對象
方法區(qū)中類靜態(tài)屬性引用的對象
方法區(qū)中常量引用的對象
Java虛擬機內(nèi)部引用
所有被同步鎖持有的對象
而在Java中的不可達對象有可能會逃脫。即使在可達性分析法中不可達的對象，也并非是“非死不可”的，這時候它們暫時處于“緩刑階段”，要真正宣告一個對象死亡，至少要經(jīng)歷兩次標(biāo)記過程；此外Java中由于存在運行時常量池和類，因此也需要對運行時常量池和方法區(qū)的類進行清理。
而Go的選擇就相對簡單一點，即全局變量和G Stack中的引用指針，簡單來說就是全局量和go程中的引用指針。因為Go中沒有類的封裝概念，因而Gc Root選擇也相對簡單一些。
寫屏障
為了解決并發(fā)三色可達性分析中的懸掛指針問題，出現(xiàn)了2種解決方案，分別是分別是“Dijkstra插入寫屏障”和“Yuasa刪除寫屏障”
在java中，對上述2種方法都有應(yīng)用，比如CMS是基于Dijkstra插入寫屏障做并發(fā)標(biāo)記的，G1、Shenandoah則是使用Yuasa刪除寫屏障來實現(xiàn)的
在 Go 語言 v1.7 版本之前，運行時會使用 Dijkstra 插入寫屏障保證強三色不變性，Go 語言在 v1.8 組合 Dijkstra 插入寫屏障和 Yuasa 刪除寫屏障構(gòu)成了混合寫屏障，混合寫屏障結(jié)合兩者特點，通過以下方式實現(xiàn)并發(fā)穩(wěn)定的gc：
將棧上的對象全部掃描并標(biāo)記為黑色
GC期間，任何在棧上創(chuàng)建的新對象，均為黑色。
被刪除的對象標(biāo)記為灰色。
被添加的對象標(biāo)記為灰色。
由于要保證棧的運行效率，混合寫屏障是針對于堆區(qū)使用的。即棧區(qū)不會觸發(fā)寫屏障，只有堆區(qū)觸發(fā)，由于棧區(qū)初始標(biāo)記的可達節(jié)點均為黑色節(jié)點，因而也不需要第二次STW下的掃描。本質(zhì)上是融合了插入屏障和刪除屏障的特點，解決了插入屏障需要二次掃描的問題。同時針對于堆區(qū)和棧區(qū)采用不同的策略，保證棧的運行效率不受損。
總結(jié)
| GC區(qū)域 | Java堆和方法區(qū) | Go堆 |
| 觸發(fā)GC時機 | 分代收集導(dǎo)致觸發(fā)時機很多 | 申請內(nèi)存、手動觸發(fā)、定時觸發(fā) |
| 垃圾收集算法 | 分代收集。在新生代（“標(biāo)記-復(fù)制”）；老年代（“標(biāo)記-清除”或“標(biāo)記-整理”） | 標(biāo)記清除算法 |
| 垃圾種類 | 死亡對象（可能會逃脫）、廢棄常量和無用的類 | 全局變量和G Stack中的引用指針 |
| 標(biāo)記階段 | 三色可達性分析算法（插入寫屏障，刪除寫屏障） | 三色可達性分析算法(混合寫屏障) |
| 空間壓縮整理 | 是 | 否 |
| 內(nèi)存分配 | 指針碰撞/空閑列表 | span內(nèi)存池 |
| 垃圾碎片解決方案 | 分代GC、對象移動、劃分region等設(shè)計 | Go語言span內(nèi)存池、tcmalloc分配機制、對象可以分配在棧上、對象池 |
從垃圾回收的角度來說，經(jīng)過多代發(fā)展，Java的垃圾回收機制較為完善，Java劃分新生代、老年代來存儲對象。對象通常會在新生代分配內(nèi)存，多次存活的對象會被移到老年代，由于新生代存活率低，產(chǎn)生空間碎片的可能性高，通常選用“標(biāo)記-復(fù)制”作為回收算法，而老年代存活率高，通常選用“標(biāo)記-清除”或“標(biāo)記-整理”作為回收算法，壓縮整理空間。
Go是非分代的、并發(fā)的、基于三色標(biāo)記和清除的垃圾回收器，它的優(yōu)勢要結(jié)合它tcmalloc內(nèi)存分配策略才能體現(xiàn)出來，因為小微對象的分配均有自己的內(nèi)存池，所有的碎片都能被完美復(fù)用，所以GC不用考慮空間碎片的問題。
參考文獻
Go語言設(shè)計與實現(xiàn)
一個專家眼中的Go與Java垃圾回收算法大對比
Go語言問題集
CMS垃圾收集器
Golang v 1.16版本源碼
《深入理解Java虛擬機：JVM高級特性與最佳實踐（第3版）》—機械工業(yè)出版社
大家可以加我微信，交個朋友，拉你進高端技術(shù)交流群，認(rèn)識更多朋友，圈子很重要。
- END -
看完一鍵三連在看，轉(zhuǎn)發(fā)，點贊
是對文章最大的贊賞，極客重生感謝你
推薦閱讀
C++內(nèi)存管理全景指南
JVM底層原理解析
深入理解RCU|核心原理
總結(jié)
以上是生活随笔為你收集整理的一文搞懂JAVA与GO垃圾回收的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 深入理解RCU | RCU源码剖析
- 下一篇： 后端技术趋势指南|如何选择自己的技术方向