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