前言
這篇文章主要介紹Go內存分配和Go內存管理，會輕微涉及內存申請和釋放，以及Go垃圾回收。從非常宏觀的角度看，Go的內存管理就是下圖這個樣子，我們今天主要關注其中標紅的部分。
Go這門語言拋棄了C/C++中的開發者管理內存的方式，實現了主動申請與主動釋放管理，增加了逃逸分析和GC，將開發者從內存管理中釋放出來，讓開發者有更多的精力去關注軟件設計，而不是底層的內存問題。這是Go語言成為高生產力語言的原因之一。
我們不需要精通內存的管理，因為它確實很復雜，但掌握內存的管理，可以讓你寫出更高質量的代碼，另外，還能助你定位Bug。這篇文章采用層層遞進的方式，依次會介紹關於存儲的基本知識，Go內存管理的 “前輩” TCMalloc，然后是Go的內存管理和分配，最后是總結。這么做的目的是，希望各位能通過全局的認識和思考，擁有更好的編碼思維和架構思維。
正文
1. 存儲基礎知識回顧
這部分我們簡單回顧一下計算機存儲體系、虛擬內存、棧和堆，以及堆內存的管理，這部分內容對理解和掌握Go內存管理比較重要。
1.1. 存儲金字塔
這幅圖表達了計算機的存儲體系，從上至下的訪問速度越來越慢，訪問時間越來越長。從上至下依次是：
- CPU寄存器
- CPU Cache
- 內存
- 硬盤等輔助存儲設備
- 鼠標等外接設備
你有沒有思考過下面2個簡單的問題，如果沒有不妨想想：
- 如果CPU直接訪問硬盤，CPU能充分利用嗎？
- 如果CPU直接訪問內存，CPU能充分利用嗎？
CPU速度很快，但硬盤等持久存儲很慢，如果CPU直接訪問磁盤，磁盤可以拉低CPU的速度，機器整體性能就會低下，為了彌補這2個硬件之間的速率差異，所以在CPU和磁盤之間增加了比磁盤快很多的內存。
然而，CPU跟內存的速率也不是相同的，從上圖可以看到，CPU的速率提高的很快（摩爾定律），然而內存速率增長的很慢，雖然CPU的速率現在增加的很慢了，但是內存的速率也沒增加多少，速率差距很大，從1980年開始CPU和內存速率差距在不斷拉大，為了彌補這2個硬件之間的速率差異，所以在CPU跟內存之間增加了比內存更快的Cache，Cache是內存數據的緩存，可以降低CPU訪問內存的時間。
三級Cache分別是L1、L2、L3，它們的速率是三個不同的層級，L1速率最快，與CPU速率最接近，是RAM速率的100倍，L2速率就降到了RAM的25倍，L3的速率更靠近RAM的速率。
看到這了，你有沒有Get到整個存儲體系的分層設計？自頂向下，速率越來越低，訪問時間越來越長，從磁盤到CPU寄存器，上一層都可以看做是下一層的緩存。看了分層設計，下面開始正式介紹內存。
1.2. 虛擬內存
虛擬內存是當代操作系統必備的一項重要功能，對於進程而言虛擬內存屏蔽了底層了RAM和磁盤，並向進程提供了遠超物理內存大小的內存空間。我們看一下虛擬內存的分層設計。
上圖展示了某進程訪問數據，當Cache沒有命中的時候，訪問虛擬內存獲取數據的過程。在訪問內存，實際訪問的是虛擬內存，虛擬內存通過頁表查看，當前要訪問的虛擬內存地址，是否已經加載到了物理內存。如果已經在物理內存，則取物理內存數據，如果沒有對應的物理內存，則從磁盤加載數據到物理內存，並把物理內存地址和虛擬內存地址更新到頁表。
物理內存就是磁盤存儲緩存層，在沒有虛擬內存的時代，物理內存對所有進程是共享的，多進程同時訪問同一個物理內存會存在並發問題。而引入虛擬內存后，每個進程都有各自的虛擬內存，內存的並發訪問問題的粒度從多進程級別，可以降低到多線程級別。
1.3. 棧和堆
我們現在從虛擬內存，再進一層，看虛擬內存中的棧和堆，也就是進程對內存的管理。
上圖展示了一個進程的虛擬內存划分，代碼中使用的內存地址都是虛擬內存地址，而不是實際的物理內存地址。棧和堆只是虛擬內存上2塊不同功能的內存區域：
- 棧在高地址，從高地址向低地址增長
- 堆在低地址，從低地址向高地址增長
棧和堆相比有這么幾個好處：
- 棧的內存管理簡單，分配比堆上快。
- 棧的內存不需要回收，而堆需要進行回收，無論是主動free，還是被動的垃圾回收，這都需要花費額外的CPU。
- 棧上的內存有更好的局部性，堆上內存訪問就不那么友好了，CPU訪問的2塊數據可能在不同的頁上，CPU訪問數據的時間可能就上去了。
1.4. 堆內存管理
我們再進一層，當我們說內存管理的時候，主要是指堆內存的管理，因為棧的內存管理不需要程序去操心，這小節看下堆內存管理到底完成了什么。如上圖所示主要是3部分，分別是分配內存塊，回收內存塊和組織內存塊。
在一個最簡單的內存管理中，堆內存最初會是一個完整的大塊，即未分配任何內存。當發現內存申請的時候，堆內存就會從未分配內存分割出一個小內存塊(block)，然后用鏈表把所有內存塊連接起來。需要一些信息描述每個內存塊的基本信息，比如大小(size)、是否使用中(used)和下一個內存塊的地址(next)，內存塊實際數據存儲在data中。
一個內存塊包含了3類信息，如下圖所示，元數據、用戶數據和對齊字段，內存對齊是為了提高訪問效率。下圖申請5Byte內存的時候，就需要進行內存對齊。
釋放內存實質是把使用的內存塊從鏈表中取出來，然后標記為未使用，當分配內存塊的時候，可以從未使用內存塊中優先查找大小相近的內存塊，如果找不到，再從未分配的內存中分配內存。
上面這個簡單的設計中還沒考慮內存碎片的問題，因為隨着內存不斷的申請和釋放，內存上會存在大量的碎片，降低內存的使用率。為了解決內存碎片，可以將2個連續的未使用的內存塊合並，減少碎片。
以上就是內存管理的基本思路，關於基本的內存管理，想了解更多，可以閱讀這篇文章《Writing a Memory Allocator》，本節的3張圖片也是來自這篇文章。
2. TCMalloc
TCMalloc是Thread Cache Malloc的簡稱，是Go內存管理的起源，Go的內存管理是借鑒了TCMalloc，隨着Go的迭代，Go的內存管理與TCMalloc不一致地方在不斷擴大，但其主要思想、原理和概念都是和TCMalloc一致的，如果跳過TCMalloc直接去看Go的內存管理，也許你會似懂非懂。
掌握TCMalloc的理念，無需去關注過多的源碼細節，就可以為掌握Go的內存管理打好基礎，基礎打好了，后面知識才扎實。
在Linux操作系統中，其實有不少的內存管理庫，比如glibc的ptmalloc，FreeBSD的jemalloc，Google的tcmalloc等等，為何會出現這么多的內存管理庫？本質都是在多線程編程下，追求更高內存管理效率：更快的分配是主要目的。
我們前面提到引入虛擬內存后，讓內存的並發訪問問題的粒度從多進程級別，降低到多線程級別。然而同一進程下的所有線程共享相同的內存空間，它們申請內存時需要加鎖，如果不加鎖就存在同一塊內存被2個線程同時訪問的問題。
TCMalloc的做法是什么呢？為每個線程預分配一塊緩存，線程申請小內存時，可以從緩存分配內存，這樣有2個好處：
- 為線程預分配緩存需要進行1次系統調用，后續線程申請小內存時直接從緩存分配，都是在用戶態執行的，沒有了系統調用，縮短了內存總體的分配和釋放時間，這是快速分配內存的第二個層次。
- 多個線程同時申請小內存時，從各自的緩存分配，訪問的是不同的地址空間，從而無需加鎖，把內存並發訪問的粒度進一步降低了，這是快速分配內存的第三個層次。
2.1. 基本原理
下面就簡單介紹下TCMalloc，細致程度夠我們理解Go的內存管理即可。
結合上圖，介紹TCMalloc的幾個重要概念：
- Page
操作系統對內存管理以頁為單位，TCMalloc也是這樣，只不過TCMalloc里的Page大小與操作系統里的大小並不一定相等，而是倍數關系。《TCMalloc解密》里稱x64下Page大小是8KB。
- Span
一組連續的Page被稱為Span，比如可以有2個頁大小的Span，也可以有16頁大小的Span，Span比Page高一個層級，是為了方便管理一定大小的內存區域，Span是TCMalloc中內存管理的基本單位。
- ThreadCache
ThreadCache是每個線程各自的Cache，一個Cache包含多個空閑內存塊鏈表，每個鏈表連接的都是內存塊，同一個鏈表上內存塊的大小是相同的，也可以說按內存塊大小，給內存塊分了個類，這樣可以根據申請的內存大小，快速從合適的鏈表選擇空閑內存塊。由於每個線程有自己的ThreadCache，所以ThreadCache訪問是無鎖的。
- CentralCache
CentralCache是所有線程共享的緩存，也是保存的空閑內存塊鏈表，鏈表的數量與ThreadCache中鏈表數量相同，當ThreadCache的內存塊不足時，可以從CentralCache獲取內存塊；當ThreadCache內存塊過多時，可以放回CentralCache。由於CentralCache是共享的，所以它的訪問是要加鎖的。
- PageHeap
PageHeap是對堆內存的抽象，PageHeap存的也是若干鏈表，鏈表保存的是Span。當CentralCache的內存不足時，會從PageHeap獲取空閑的內存Span，然后把1個Span拆成若干內存塊，添加到對應大小的鏈表中並分配內存；當CentralCache的內存過多時，會把空閑的內存塊放回PageHeap中。
如下圖所示，分別是1頁Page的Span鏈表，2頁Page的Span鏈表等，最后是large span set，這個是用來保存中大對象的。毫無疑問，PageHeap也是要加鎖的。
前文提到了小、中、大對象，Go內存管理中也有類似的概念，我們看一眼TCMalloc的定義：
- 小對象大小：0~256KB
- 中對象大小：257~1MB
- 大對象大小：>1MB
小對象的分配流程：ThreadCache -> CentralCache -> HeapPage，大部分時候，ThreadCache緩存都是足夠的，不需要去訪問CentralCache和HeapPage，無系統調用配合無鎖分配，分配效率是非常高的。
中對象分配流程：直接在PageHeap中選擇適當的大小即可，128 Page的Span所保存的最大內存就是1MB。
大對象分配流程：從large span set選擇合適數量的頁面組成span，用來存儲數據。
通過本節的介紹，你應當對TCMalloc主要思想有一定了解了，我建議再回顧一下上面的內容。
3. Go內存管理
前文提到Go內存管理源自TCMalloc，但它比TCMalloc還多了2件東西：逃逸分析和垃圾回收，這是2項提高生產力的絕佳武器。這一大章節，我們先介紹Go內存管理和Go內存分配，最后涉及一點垃圾回收和內存釋放。
3.1. Go內存管理的基本概念
Go內存管理的許多概念在TCMalloc中已經有了，含義是相同的，只是名字有一些變化。先給大家上一幅宏觀的圖，借助圖一起來介紹。
- Page
與TCMalloc中的Page相同，x64架構下1個Page的大小是8KB。上圖的最下方，1個淺藍色的長方形代表1個Page。
- Span
Span與TCMalloc中的Span相同，Span是內存管理的基本單位，代碼中為mspan，一組連續的Page組成1個Span，所以上圖一組連續的淺藍色長方形代表的是一組Page組成的1個Span，另外，1個淡紫色長方形為1個Span。
- mcache
mcache與TCMalloc中的ThreadCache類似，mcache保存的是各種大小的Span，並按Span class分類，小對象直接從mcache分配內存，它起到了緩存的作用，並且可以無鎖訪問。但是mcache與ThreadCache也有不同點，TCMalloc中是每個線程1個ThreadCache，Go中是每個P擁有1個mcache。因為在Go程序中，當前最多有GOMAXPROCS個線程在運行，所以最多需要GOMAXPROCS個mcache就可以保證各線程對mcache的無鎖訪問，線程的運行又是與P綁定的，把mcache交給P剛剛好。
- mcentral
mcentral與TCMalloc中的CentralCache類似，是所有線程共享的緩存，需要加鎖訪問。它按Span級別對Span分類，然后串聯成鏈表，當mcache的某個級別Span的內存被分配光時，它會向mcentral申請1個當前級別的Span。
但是mcentral與CentralCache也有不同點，CentralCache是每個級別的Span有1個鏈表，mcache是每個級別的Span有2個鏈表，這和mcache申請內存有關，稍后我們再解釋。
- mheap
mheap與TCMalloc中的PageHeap類似，它是堆內存的抽象，把從OS申請出的內存頁組織成Span，並保存起來。當mcentral的Span不夠用時會向mheap申請內存，而mheap的Span不夠用時會向OS申請內存。mheap向OS的內存申請是按頁來的，然后把申請來的內存頁生成Span組織起來，同樣也是需要加鎖訪問的。
但是mheap與PageHeap也有不同點：mheap把Span組織成了樹結構，而不是鏈表，並且還是2棵樹，然后把Span分配到heapArena進行管理，它包含地址映射和span是否包含指針等位圖，這樣做的主要原因是為了更高效的利用內存：分配、回收和再利用。
- object size：代碼里簡稱size，指申請內存的對象大小。
- size class：代碼里簡稱class，它是size的級別，相當於把size歸類到一定大小的區間段，比如size[1,8]屬於size class 1，size(8,16]屬於size class 2。
- span class：指span的級別，但span class的大小與span的大小並沒有正比關系。span class主要用來和size class做對應，1個size class對應2個span class，2個span class的span大小相同，只是功能不同，1個用來存放包含指針的對象，一個用來存放不包含指針的對象，不包含指針對象的Span就無需GC掃描了。
- num of page：代碼里簡稱npage，代表Page的數量，其實就是Span包含的頁數，用來分配內存。
3.2. Go內存分配
Go中的內存分類並不像TCMalloc那樣分成小、中、大對象，但是它的小對象里又細分了一個Tiny對象，Tiny對象指大小在1Byte到16Byte之間並且不包含指針的對象。小對象和大對象只用大小划定，無其他區分。
小對象是在mcache中分配的，而大對象是直接從mheap分配的，從小對象的內存分配看起。
3.1.1. 小對象的內存分配
大小轉換這一小節，我們介紹了轉換表，size class從1到66共66個，代碼中_NumSizeClasses=67代表了實際使用的size class數量，即67個，從0到67，size class 0實際並未使用到。
上文提到1個size class對應2個span class：
numSpanClasses = _NumSizeClasses * 2 numSpanClasses為span class的數量為134個，所以span class的下標是從0到133，所以上圖中mcache標注了的span class是，span class 0到span class 133。每1個span class都指向1個span，也就是mcache最多有134個span。
- 為對象尋找span
尋找span的流程如下：
- 計算對象所需內存大小size
- 根據size到size class映射，計算出所需的size class
- 根據size class和對象是否包含指針計算出span class
- 獲取該span class指向的span
以分配一個不包含指針的，大小為24Byte的對象為例，根據映射表：
// class bytes/obj bytes/span objects tail waste max waste
// 1 8 8192 1024 0 87.50% // 2 16 8192 512 0 43.75% // 3 32 8192 256 0 46.88% // 4 48 8192 170 32 31.52%對應的size class為3，它的對象大小范圍是(16,32]Byte，24Byte剛好在此區間，所以此對象的size class為3。
Size class到span class的計算如下：
// noscan為true代表對象不包含指針 func makeSpanClass(sizeclass uint8, noscan bool) spanClass { return spanClass(sizeclass<<1) | spanClass(bool2int(noscan)) } 所以對應的span class為7，所以該對象需要的是span class 7指向的span。
span class = 3 << 1 | 1 = 7 - 從span分配對象空間
Span可以按對象大小切成很多份，這些都可以從映射表上計算出來，以size class 3對應的span為例，span大小是8KB，每個對象實際所占空間為32Byte，這個span就被分成了256塊，可以根據span的起始地址計算出每個對象塊的內存地址。
隨着內存的分配，span中的對象內存塊，有些被占用，有些未被占用，比如上圖，整體代表1個span，藍色塊代表已被占用內存，綠色塊代表未被占用內存。當分配內存時，只要快速找到第一個可用的綠色塊，並計算出內存地址即可，如果需要還可以對內存塊數據清零。
當span內的所有內存塊都被占用時，沒有剩余空間繼續分配對象，mcache會向mcentral申請1個span，mcache拿到span后繼續分配對象。
- mcache向mcentral申請span
mcentral和mcache一樣，都是0~133這134個span class級別，但每個級別都保存了2個span list，即2個span鏈表：
- nonempty：這個鏈表里的span，所有span都至少有1個空閑的對象空間。這些span是mcache釋放span時加入到該鏈表的。
- empty：這個鏈表里的span，所有的span都不確定里面是否有空閑的對象空間。當一個span交給mcache的時候，就會加入到empty鏈表。
這兩個東西名稱一直有點繞，建議直接把empty理解為沒有對象空間就好了。
mcache向mcentral申請span時，mcentral會先從nonempty搜索滿足條件的span，如果沒有找到再從emtpy搜索滿足條件的span，然后把找到的span交給mcache。
- mheap的span管理
mheap里保存了兩棵二叉排序樹，按span的page數量進行排序：
- free：free中保存的span是空閑並且非垃圾回收的span。
- scav：scav中保存的是空閑並且已經垃圾回收的span。
如果是垃圾回收導致的span釋放，span會被加入到scav，否則加入到free，比如剛從OS申請的的內存也組成的Span。
mheap中還有arenas，由一組heapArena組成，每一個heapArena都包含了連續的pagesPerArena個span，這個主要是為mheap管理span和垃圾回收服務。mheap本身是一個全局變量，它里面的數據，也都是從OS直接申請來的內存，並不在mheap所管理的那部分內存以內。
- mcentral向mheap申請span
當mcentral向mcache提供span時，如果empty里也沒有符合條件的span，mcentral會向mheap申請span。
此時，mcentral需要向mheap提供需要的內存頁數和span class級別，然后它優先從free中搜索可用的span。如果沒有找到，會從scav中搜索可用的span。如果還沒有找到，它會向OS申請內存，再重新搜索2棵樹，必然能找到span。如果找到的span比需要的span大，則把span進行分割成2個span，其中1個剛好是需求大小，把剩下的span再加入到free中去，然后設置需要的span的基本信息，然后交給mcentral。
- mheap向OS申請內存
當mheap沒有足夠的內存時，mheap會向OS申請內存，把申請的內存頁保存為span，然后把span插入到free樹。在32位系統中，mheap還會預留一部分空間，當mheap沒有空間時，先從預留空間申請，如果預留空間內存也沒有了，才向OS申請。
3.1.2. 大對象的內存分配
大對象的分配比小對象省事多了，99%的流程與mcentral向mheap申請內存的相同，所以不重復介紹了。不同的一點在於mheap會記錄一點大對象的統計信息，詳情見mheap.alloc_m()。
3.2. Go垃圾回收和內存釋放
如果只申請和分配內存，內存終將枯竭。Go使用垃圾回收收集不再使用的span，調用mspan.scavenge()把span釋放還給OS（並非真釋放，只是告訴OS這片內存的信息無用了，如果你需要的話，收回去好了），然后交給mheap，mheap對span進行span的合並，把合並后的span加入scav樹中，等待再分配內存時，由mheap進行內存再分配，Go垃圾回收也是一個很強的主題，計划后面單獨寫一篇文章介紹。
現在我們關注一下，Go程序是怎么把內存釋放給操作系統的？釋放內存的函數是sysUnused，它會被mspan.scavenge()調用:
func sysUnused(v unsafe.Pointer, n uintptr) { // MADV_FREE_REUSABLE is like MADV_FREE except it also propagates // accounting information about the process to task_info. madvise(v, n, _MADV_FREE_REUSABLE) } 注釋說 _MADV_FREE_REUSABLE 與 MADV_FREE 的功能類似，它的功能是給內核提供一個建議：這個內存地址區間的內存已經不再使用，可以進行回收。但內核是否回收，以及什么時候回收，這就是內核的事情了。如果內核真把這片內存回收了，當Go程序再使用這個地址時，內核會重新進行虛擬地址到物理地址的映射。所以在內存充足的情況下，內核也沒有必要立刻回收內存。
4. Go的棧內存
最后提一下棧內存。從一個宏觀的角度看，內存管理不應當只有堆，也應當有棧。每個goroutine都有自己的棧，棧的初始大小是2KB，100萬的goroutine會占用2G，但goroutine的棧會在2KB不夠用時自動擴容，當擴容為4KB的時候，百萬goroutine會占用4GB。
總結
Go的內存分配原理就不再回顧了，它主要強調兩個重要的思想：
- 使用緩存提高效率。在存儲的整個體系中到處可見緩存的思想，Go內存分配和管理也使用了緩存，利用緩存一是減少了系統調用的次數，二是降低了鎖的粒度、減少加鎖的次數，從這2點提高了內存管理效率。
- 以空間換時間，提高內存管理效率。空間換時間是一種常用的性能優化思想，這種思想其實非常普遍，比如Hash、Map、二叉排序樹等數據結構的本質就是空間換時間，在數據庫中也很常見，比如數據庫索引、索引視圖和數據緩存等，再如Redis等緩存數據庫也是空間換時間的思想。