詳解Go語言的內存模型及堆的分配管理

語言: CN / TW / HK

這篇文章主要介紹Go內存分配和Go內存管理,會輕微涉及內存申請和釋放,以及Go垃圾回收。從非常宏觀的角度看,Go的內存管理就是下圖這個樣子,我們今天主要關注其中標紅的部分。

Go這門語言拋棄了C/C++中的開發者管理內存的方式,實現了主動申請與主動釋放管理,增加了逃逸分析和GC,將開發者從內存管理中釋放出來,讓開發者有更多的精力去關注軟件設計,而不是底層的內存問題。這是Go語言成為高生產力語言的原因之一。

我們不需要精通內存的管理,因為它確實很複雜,但掌握內存的管理,可以讓你寫出更高質量的代碼,另外,還能助你定位Bug。這篇文章採用層層遞進的方式,依次會介紹關於存儲的基本知識,Go內存管理的 “前輩” TCMalloc,然後是Go的內存管理和分配,最後是總結。這麼做的目的是,希望各位能通過全局的認識和思考,擁有更好的編碼思維和架構思維。

正文

1. 存儲基礎知識回顧

這部分我們簡單回顧一下計算機存儲體系、虛擬內存、棧和堆,以及堆內存的管理,這部分內容對理解和掌握Go內存管理比較重要。

1.1. 存儲金字塔

這幅圖表達了計算機的存儲體系,從上至下的訪問速度越來越慢,訪問時間越來越長。從上至下依次是:

  • CPU寄存器
  • CPU Cache
  • 內存
  • 硬盤等輔助存儲設備
  • 鼠標等外接設備

你有沒有思考過下面2個簡單的問題,如果沒有不妨想想:

  1. 如果CPU直接訪問硬盤,CPU能充分利用嗎?
  2. 如果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. 為線程預分配緩存需要進行1次系統調用,後續線程申請小內存時直接從緩存分配,都是在用户態執行的,沒有了系統調用,縮短了內存總體的分配和釋放時間,這是快速分配內存的第二個層次。

  2. 多個線程同時申請小內存時,從各自的緩存分配,訪問的是不同的地址空間,從而無需加鎖,把內存併發訪問的粒度進一步降低了,這是快速分配內存的第三個層次。

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是否包含指針等位圖,這樣做的主要原因是為了更高效的利用內存:分配、回收和再利用。

  1. object size:代碼裏簡稱size,指申請內存的對象大小。
  2. size class:代碼裏簡稱class,它是size的級別,相當於把size歸類到一定大小的區間段,比如size[1,8]屬於size class 1,size(8,16]屬於size class 2。
  3. span class:指span的級別,但span class的大小與span的大小並沒有正比關係。span class主要用來和size class做對應,1個size class對應2個span class,2個span class的span大小相同,只是功能不同,1個用來存放包含指針的對象,一個用來存放不包含指針的對象,不包含指針對象的Span就無需GC掃描了。
  4. 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的流程如下:

  1. 計算對象所需內存大小size
  2. 根據size到size class映射,計算出所需的size class
  3. 根據size class和對象是否包含指針計算出span class
  4. 獲取該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鏈表:

  1. nonempty:這個鏈表裏的span,所有span都至少有1個空閒的對象空間。這些span是mcache釋放span時加入到該鏈表的。
  2. empty:這個鏈表裏的span,所有的span都不確定裏面是否有空閒的對象空間。當一個span交給mcache的時候,就會加入到empty鏈表。

這兩個東西名稱一直有點繞,建議直接把empty理解為沒有對象空間就好了。

mcache向mcentral申請span時,mcentral會先從nonempty搜索滿足條件的span,如果沒有找到再從emtpy搜索滿足條件的span,然後把找到的span交給mcache。

  • mheap的span管理

mheap裏保存了兩棵二叉排序樹,按span的page數量進行排序:

  1. free:free中保存的span是空閒並且非垃圾回收的span。
  2. 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的內存分配原理就不再回顧了,它主要強調兩個重要的思想:

  1. 使用緩存提高效率。在存儲的整個體系中到處可見緩存的思想,Go內存分配和管理也使用了緩存,利用緩存一是減少了系統調用的次數,二是降低了鎖的粒度、減少加鎖的次數,從這2點提高了內存管理效率。

  2. 以空間換時間,提高內存管理效率。空間換時間是一種常用的性能優化思想,這種思想其實非常普遍,比如Hash、Map、二叉排序樹等數據結構的本質就是空間換時間,在數據庫中也很常見,比如數據庫索引、索引視圖和數據緩存等,再如Redis等緩存數據庫也是空間換時間的思想。

本帳號將持續分享後端技術乾貨,包括虛擬機基礎,多線程編程,高性能框架,異步、緩存和消息中間件,分佈式和微服務,架構學習和進階等學習資料和文章。