從非常宏觀的角度看，Go的內(nèi)存管理就是下圖這個(gè)樣子。

Go這門語言拋棄了C/C++中的開發(fā)者管理內(nèi)存的方式，實(shí)現(xiàn)了主動(dòng)申請(qǐng)與主動(dòng)釋放管理，增加了逃逸分析和GC，將開發(fā)者從內(nèi)存管理中釋放出來，讓開發(fā)者有更多的精力去關(guān)注軟件設(shè)計(jì)，而不是底層的內(nèi)存問題。這是Go語言成為高生產(chǎn)力語言的原因之一。

我們不需要精通內(nèi)存的管理，因?yàn)樗_實(shí)很復(fù)雜，但掌握內(nèi)存的管理，可以讓你寫出更高質(zhì)量的代碼，另外，還能助你定位Bug。這篇文章采用層層遞進(jìn)的方式，依次會(huì)介紹關(guān)于存儲(chǔ)的基本知識(shí)，Go內(nèi)存管理的 “前輩” TCMalloc，然后是Go的內(nèi)存管理和分配，最后是總結(jié)。這么做的目的是，希望各位能通過全局的認(rèn)識(shí)和思考，擁有更好的編碼思維和架構(gòu)思維。

正文

1. 存儲(chǔ)基礎(chǔ)知識(shí)回顧

這部分我們簡單回顧一下計(jì)算機(jī)存儲(chǔ)體系、虛擬內(nèi)存、棧和堆，以及堆內(nèi)存的管理，這部分內(nèi)容對(duì)理解和掌握Go內(nèi)存管理比較重要。

1.1. 存儲(chǔ)金字塔

這幅圖表達(dá)了計(jì)算機(jī)的存儲(chǔ)體系，從上至下的訪問速度越來越慢，訪問時(shí)間越來越長。從上至下依次是：

• CPU寄存器
• CPU Cache
• 內(nèi)存
• 硬盤等輔助存儲(chǔ)設(shè)備
• 鼠標(biāo)等外接設(shè)備

你有沒有思考過下面2個(gè)簡單的問題，如果沒有不妨想想：

• 如果CPU直接訪問硬盤，CPU能充分利用嗎？
• 如果CPU直接訪問內(nèi)存，CPU能充分利用嗎？

CPU速度很快，但硬盤等持久存儲(chǔ)很慢，如果CPU直接訪問磁盤，磁盤可以拉低CPU的速度，機(jī)器整體性能就會(huì)低下，為了彌補(bǔ)這2個(gè)硬件之間的速率差異，所以在CPU和磁盤之間增加了比磁盤快很多的內(nèi)存。

然而，CPU跟內(nèi)存的速率也不是相同的，從上圖可以看到，CPU的速率提高的很快（摩爾定律），然而內(nèi)存速率增長的很慢，雖然CPU的速率現(xiàn)在增加的很慢了，但是內(nèi)存的速率也沒增加多少，速率差距很大，從1980年開始CPU和內(nèi)存速率差距在不斷拉大，為了彌補(bǔ)這2個(gè)硬件之間的速率差異，所以在CPU跟內(nèi)存之間增加了比內(nèi)存更快的Cache，Cache是內(nèi)存數(shù)據(jù)的緩存，可以降低CPU訪問內(nèi)存的時(shí)間。

三級(jí)Cache分別是L1、L2、L3，它們的速率是三個(gè)不同的層級(jí)，L1速率最快，與CPU速率最接近，是RAM速率的100倍，L2速率就降到了RAM的25倍，L3的速率更靠近RAM的速率。

看到這了，你有沒有Get到整個(gè)存儲(chǔ)體系的分層設(shè)計(jì)？自頂向下，速率越來越低，訪問時(shí)間越來越長，從磁盤到CPU寄存器，上一層都可以看做是下一層的緩存?？戳朔謱釉O(shè)計(jì)，下面開始正式介紹內(nèi)存。

1.2. 虛擬內(nèi)存

虛擬內(nèi)存是當(dāng)代操作系統(tǒng)必備的一項(xiàng)重要功能，對(duì)于進(jìn)程而言虛擬內(nèi)存屏蔽了底層了RAM和磁盤，并向進(jìn)程提供了遠(yuǎn)超物理內(nèi)存大小的內(nèi)存空間。我們看一下虛擬內(nèi)存的分層設(shè)計(jì)。

上圖展示了某進(jìn)程訪問數(shù)據(jù)，當(dāng)Cache沒有命中的時(shí)候，訪問虛擬內(nèi)存獲取數(shù)據(jù)的過程。在訪問內(nèi)存，實(shí)際訪問的是虛擬內(nèi)存，虛擬內(nèi)存通過頁表查看，當(dāng)前要訪問的虛擬內(nèi)存地址，是否已經(jīng)加載到了物理內(nèi)存。如果已經(jīng)在物理內(nèi)存，則取物理內(nèi)存數(shù)據(jù)，如果沒有對(duì)應(yīng)的物理內(nèi)存，則從磁盤加載數(shù)據(jù)到物理內(nèi)存，并把物理內(nèi)存地址和虛擬內(nèi)存地址更新到頁表。

物理內(nèi)存就是磁盤存儲(chǔ)緩存層，在沒有虛擬內(nèi)存的時(shí)代，物理內(nèi)存對(duì)所有進(jìn)程是共享的，多進(jìn)程同時(shí)訪問同一個(gè)物理內(nèi)存會(huì)存在并發(fā)問題。而引入虛擬內(nèi)存后，每個(gè)進(jìn)程都有各自的虛擬內(nèi)存，內(nèi)存的并發(fā)訪問問題的粒度從多進(jìn)程級(jí)別，可以降低到多線程級(jí)別。

1.3. 棧和堆

我們現(xiàn)在從虛擬內(nèi)存，再進(jìn)一層，看虛擬內(nèi)存中的棧和堆，也就是進(jìn)程對(duì)內(nèi)存的管理。

上圖展示了一個(gè)進(jìn)程的虛擬內(nèi)存劃分，代碼中使用的內(nèi)存地址都是虛擬內(nèi)存地址，而不是實(shí)際的物理內(nèi)存地址。棧和堆只是虛擬內(nèi)存上2塊不同功能的內(nèi)存區(qū)域：

• 棧在高地址，從高地址向低地址增長

• 堆在低地址，從低地址向高地址增長

棧和堆相比有這么幾個(gè)好處：

• 棧的內(nèi)存管理簡單，分配比堆上快。
• 棧的內(nèi)存不需要回收，而堆需要進(jìn)行回收，無論是主動(dòng)free，還是被動(dòng)的垃圾回收，這都需要花費(fèi)額外的CPU。
• 棧上的內(nèi)存有更好的局部性，堆上內(nèi)存訪問就不那么友好了，CPU訪問的2塊數(shù)據(jù)可能在不同的頁上，CPU訪問數(shù)據(jù)的時(shí)間可能就上去了。

1.4. 堆內(nèi)存管理

我們?cè)龠M(jìn)一層，當(dāng)我們說內(nèi)存管理的時(shí)候，主要是指堆內(nèi)存的管理，因?yàn)闂５膬?nèi)存管理不需要程序去操心，這小節(jié)看下堆內(nèi)存管理到底完成了什么。如上圖所示主要是3部分，分別是分配內(nèi)存塊，回收內(nèi)存塊和組織內(nèi)存塊。

在一個(gè)最簡單的內(nèi)存管理中，堆內(nèi)存最初會(huì)是一個(gè)完整的大塊，即未分配任何內(nèi)存。當(dāng)發(fā)現(xiàn)內(nèi)存申請(qǐng)的時(shí)候，堆內(nèi)存就會(huì)從未分配內(nèi)存分割出一個(gè)小內(nèi)存塊(block)，然后用鏈表把所有內(nèi)存塊連接起來。需要一些信息描述每個(gè)內(nèi)存塊的基本信息，比如大小(size)、是否使用中(used)和下一個(gè)內(nèi)存塊的地址(next)，內(nèi)存塊實(shí)際數(shù)據(jù)存儲(chǔ)在data中。

一個(gè)內(nèi)存塊包含了3類信息，如下圖所示，元數(shù)據(jù)、用戶數(shù)據(jù)和對(duì)齊字段，內(nèi)存對(duì)齊是為了提高訪問效率。下圖申請(qǐng)5Byte內(nèi)存的時(shí)候，就需要進(jìn)行內(nèi)存對(duì)齊。

釋放內(nèi)存實(shí)質(zhì)是把使用的內(nèi)存塊從鏈表中取出來，然后標(biāo)記為未使用，當(dāng)分配內(nèi)存塊的時(shí)候，可以從未使用內(nèi)存塊中優(yōu)先查找大小相近的內(nèi)存塊，如果找不到，再從未分配的內(nèi)存中分配內(nèi)存。

上面這個(gè)簡單的設(shè)計(jì)中還沒考慮內(nèi)存碎片的問題，因?yàn)殡S著內(nèi)存不斷的申請(qǐng)和釋放，內(nèi)存上會(huì)存在大量的碎片，降低內(nèi)存的使用率。為了解決內(nèi)存碎片，可以將2個(gè)連續(xù)的未使用的內(nèi)存塊合并，減少碎片。

以上就是內(nèi)存管理的基本思路，關(guān)于基本的內(nèi)存管理，想了解更多，可以閱讀這篇文章《Writing a Memory Allocator》，本節(jié)的3張圖片也是來自這篇文章。

2. TCMalloc

TCMalloc是Thread Cache Malloc的簡稱，是Go內(nèi)存管理的起源，Go的內(nèi)存管理是借鑒了TCMalloc，隨著Go的迭代，Go的內(nèi)存管理與TCMalloc不一致地方在不斷擴(kuò)大，但其主要思想、原理和概念都是和TCMalloc一致的，如果跳過TCMalloc直接去看Go的內(nèi)存管理，也許你會(huì)似懂非懂。

掌握TCMalloc的理念，無需去關(guān)注過多的源碼細(xì)節(jié)，就可以為掌握Go的內(nèi)存管理打好基礎(chǔ)，基礎(chǔ)打好了，后面知識(shí)才扎實(shí)。

在Linux操作系統(tǒng)中，其實(shí)有不少的內(nèi)存管理庫，比如glibc的ptmalloc，F(xiàn)reeBSD的jemalloc，Google的tcmalloc等等，為何會(huì)出現(xiàn)這么多的內(nèi)存管理庫？本質(zhì)都是在多線程編程下，追求更高內(nèi)存管理效率：更快的分配是主要目的。

我們前面提到引入虛擬內(nèi)存后，讓內(nèi)存的并發(fā)訪問問題的粒度從多進(jìn)程級(jí)別，降低到多線程級(jí)別。然而同一進(jìn)程下的所有線程共享相同的內(nèi)存空間，它們申請(qǐng)內(nèi)存時(shí)需要加鎖，如果不加鎖就存在同一塊內(nèi)存被2個(gè)線程同時(shí)訪問的問題。

TCMalloc的做法是什么呢？為每個(gè)線程預(yù)分配一塊緩存，線程申請(qǐng)小內(nèi)存時(shí)，可以從緩存分配內(nèi)存，這樣有2個(gè)好處：

• 為線程預(yù)分配緩存需要進(jìn)行1次系統(tǒng)調(diào)用，后續(xù)線程申請(qǐng)小內(nèi)存時(shí)直接從緩存分配，都是在用戶態(tài)執(zhí)行的，沒有了系統(tǒng)調(diào)用，縮短了內(nèi)存總體的分配和釋放時(shí)間，這是快速分配內(nèi)存的第二個(gè)層次。

• 多個(gè)線程同時(shí)申請(qǐng)小內(nèi)存時(shí)，從各自的緩存分配，訪問的是不同的地址空間，從而無需加鎖，把內(nèi)存并發(fā)訪問的粒度進(jìn)一步降低了，這是快速分配內(nèi)存的第三個(gè)層次。

2.1. 基本原理

下面就簡單介紹下TCMalloc，細(xì)致程度夠我們理解Go的內(nèi)存管理即可。

結(jié)合上圖，介紹TCMalloc的幾個(gè)重要概念：

• Page

操作系統(tǒng)對(duì)內(nèi)存管理以頁為單位，TCMalloc也是這樣，只不過TCMalloc里的Page大小與操作系統(tǒng)里的大小并不一定相等，而是倍數(shù)關(guān)系?！禩CMalloc解密》里稱x64下Page大小是8KB。

• Span

一組連續(xù)的Page被稱為Span，比如可以有2個(gè)頁大小的Span，也可以有16頁大小的Span，Span比Page高一個(gè)層級(jí)，是為了方便管理一定大小的內(nèi)存區(qū)域，Span是TCMalloc中內(nèi)存管理的基本單位。

• ThreadCache

ThreadCache是每個(gè)線程各自的Cache，一個(gè)Cache包含多個(gè)空閑內(nèi)存塊鏈表，每個(gè)鏈表連接的都是內(nèi)存塊，同一個(gè)鏈表上內(nèi)存塊的大小是相同的，也可以說按內(nèi)存塊大小，給內(nèi)存塊分了個(gè)類，這樣可以根據(jù)申請(qǐng)的內(nèi)存大小，快速從合適的鏈表選擇空閑內(nèi)存塊。由于每個(gè)線程有自己的ThreadCache，所以ThreadCache訪問是無鎖的。

• CentralCache

CentralCache是所有線程共享的緩存，也是保存的空閑內(nèi)存塊鏈表，鏈表的數(shù)量與ThreadCache中鏈表數(shù)量相同，當(dāng)ThreadCache的內(nèi)存塊不足時(shí)，可以從CentralCache獲取內(nèi)存塊；當(dāng)ThreadCache內(nèi)存塊過多時(shí)，可以放回CentralCache。由于CentralCache是共享的，所以它的訪問是要加鎖的。

• PageHeap

PageHeap是對(duì)堆內(nèi)存的抽象，PageHeap存的也是若干鏈表，鏈表保存的是Span。當(dāng)CentralCache的內(nèi)存不足時(shí)，會(huì)從PageHeap獲取空閑的內(nèi)存Span，然后把1個(gè)Span拆成若干內(nèi)存塊，添加到對(duì)應(yīng)大小的鏈表中并分配內(nèi)存；當(dāng)CentralCache的內(nèi)存過多時(shí)，會(huì)把空閑的內(nèi)存塊放回PageHeap中。

如下圖所示，分別是1頁P(yáng)age的Span鏈表，2頁P(yáng)age的Span鏈表等，最后是large span set，這個(gè)是用來保存中大對(duì)象的。毫無疑問，PageHeap也是要加鎖的。

• Page

與TCMalloc中的Page相同，x64架構(gòu)下1個(gè)Page的大小是8KB。上圖的最下方，1個(gè)淺藍(lán)色的長方形代表1個(gè)Page。

• Span

Span與TCMalloc中的Span相同，Span是內(nèi)存管理的基本單位，代碼中為mspan，一組連續(xù)的Page組成1個(gè)Span，所以上圖一組連續(xù)的淺藍(lán)色長方形代表的是一組Page組成的1個(gè)Span，另外，1個(gè)淡紫色長方形為1個(gè)Span。

• mcache

mcache與TCMalloc中的ThreadCache類似，mcache保存的是各種大小的Span，并按Span class分類，小對(duì)象直接從mcache分配內(nèi)存，它起到了緩存的作用，并且可以無鎖訪問。但是mcache與ThreadCache也有不同點(diǎn)，TCMalloc中是每個(gè)線程1個(gè)ThreadCache，Go中是每個(gè)P擁有1個(gè)mcache。因?yàn)樵贕o程序中，當(dāng)前最多有GOMAXPROCS個(gè)線程在運(yùn)行，所以最多需要GOMAXPROCS個(gè)mcache就可以保證各線程對(duì)mcache的無鎖訪問，線程的運(yùn)行又是與P綁定的，把mcache交給P剛剛好。

• mcentral

mcentral與TCMalloc中的CentralCache類似，是所有線程共享的緩存，需要加鎖訪問。它按Span級(jí)別對(duì)Span分類，然后串聯(lián)成鏈表，當(dāng)mcache的某個(gè)級(jí)別Span的內(nèi)存被分配光時(shí)，它會(huì)向mcentral申請(qǐng)1個(gè)當(dāng)前級(jí)別的Span。

但是mcentral與CentralCache也有不同點(diǎn)，CentralCache是每個(gè)級(jí)別的Span有1個(gè)鏈表，mcache是每個(gè)級(jí)別的Span有2個(gè)鏈表，這和mcache申請(qǐng)內(nèi)存有關(guān)，稍后我們?cè)俳忉尅?/p>

• mheap

mheap與TCMalloc中的PageHeap類似，它是堆內(nèi)存的抽象，把從OS申請(qǐng)出的內(nèi)存頁組織成Span，并保存起來。當(dāng)mcentral的Span不夠用時(shí)會(huì)向mheap申請(qǐng)內(nèi)存，而mheap的Span不夠用時(shí)會(huì)向OS申請(qǐng)內(nèi)存。mheap向OS的內(nèi)存申請(qǐng)是按頁來的，然后把申請(qǐng)來的內(nèi)存頁生成Span組織起來，同樣也是需要加鎖訪問的。

但是mheap與PageHeap也有不同點(diǎn)：mheap把Span組織成了樹結(jié)構(gòu)，而不是鏈表，并且還是2棵樹，然后把Span分配到heapArena進(jìn)行管理，它包含地址映射和span是否包含指針等位圖，這樣做的主要原因是為了更高效的利用內(nèi)存：分配、回收和再利用。

• object size：代碼里簡稱size，指申請(qǐng)內(nèi)存的對(duì)象大小。
• size class：代碼里簡稱class，它是size的級(jí)別，相當(dāng)于把size歸類到一定大小的區(qū)間段，比如size[1,8]屬于size class 1，size(8,16]屬于size class 2。
• span class：指span的級(jí)別，但span class的大小與span的大小并沒有正比關(guān)系。span class主要用來和size class做對(duì)應(yīng)，1個(gè)size class對(duì)應(yīng)2個(gè)span class，2個(gè)span class的span大小相同，只是功能不同，1個(gè)用來存放包含指針的對(duì)象，一個(gè)用來存放不包含指針的對(duì)象，不包含指針對(duì)象的Span就無需GC掃描了。
• num of page：代碼里簡稱npage，代表Page的數(shù)量，其實(shí)就是Span包含的頁數(shù)，用來分配內(nèi)存。

3. Go內(nèi)存分配

Go中的內(nèi)存分類并不像TCMalloc那樣分成小、中、大對(duì)象，但是它的小對(duì)象里又細(xì)分了一個(gè)Tiny對(duì)象，Tiny對(duì)象指大小在1Byte到16Byte之間并且不包含指針的對(duì)象。小對(duì)象和大對(duì)象只用大小劃定，無其他區(qū)分。

小對(duì)象是在mcache中分配的，而大對(duì)象是直接從mheap分配的，從小對(duì)象的內(nèi)存分配看起。

3.1. 小對(duì)象的內(nèi)存分配

大小轉(zhuǎn)換這一小節(jié)，我們介紹了轉(zhuǎn)換表，size class從1到66共66個(gè)，代碼中_NumSizeClasses=67代表了實(shí)際使用的size class數(shù)量，即67個(gè)，從0到67，size class 0實(shí)際并未使用到。

上文提到1個(gè)size class對(duì)應(yīng)2個(gè)span class：

numSpanClasses = _NumSizeClasses * 2

numSpanClasses為span class的數(shù)量為134個(gè)，所以span class的下標(biāo)是從0到133，所以上圖中mcache標(biāo)注了的span class是，span class 0到span class 133。每1個(gè)span class都指向1個(gè)span，也就是mcache最多有134個(gè)span。

• 為對(duì)象尋找span

尋找span的流程如下：

• 計(jì)算對(duì)象所需內(nèi)存大小size
• 根據(jù)size到size class映射，計(jì)算出所需的size class
• 根據(jù)size class和對(duì)象是否包含指針計(jì)算出span class
• 獲取該span class指向的span

以分配一個(gè)不包含指針的，大小為24Byte的對(duì)象為例，根據(jù)映射表：

// 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%

對(duì)應(yīng)的size class為3，它的對(duì)象大小范圍是(16,32]Byte，24Byte剛好在此區(qū)間，所以此對(duì)象的size class為3。

Size class到span class的計(jì)算如下

// noscan為true代表對(duì)象不包含指針
func makeSpanClass(sizeclass uint8, noscan bool) spanClass {
    return spanClass(sizeclass<<1) | spanClass(bool2int(noscan))
}

所以對(duì)應(yīng)的span class為7，所以該對(duì)象需要的是span class 7指向的span。

span class = 3 << 1 | 1 = 7

• 從span分配對(duì)象空間

Span可以按對(duì)象大小切成很多份，這些都可以從映射表上計(jì)算出來，以size class 3對(duì)應(yīng)的span為例，span大小是8KB，每個(gè)對(duì)象實(shí)際所占空間為32Byte，這個(gè)span就被分成了256塊，可以根據(jù)span的起始地址計(jì)算出每個(gè)對(duì)象塊的內(nèi)存地址。

隨著內(nèi)存的分配，span中的對(duì)象內(nèi)存塊，有些被占用，有些未被占用，比如上圖，整體代表1個(gè)span，藍(lán)色塊代表已被占用內(nèi)存，綠色塊代表未被占用內(nèi)存。當(dāng)分配內(nèi)存時(shí)，只要快速找到第一個(gè)可用的綠色塊，并計(jì)算出內(nèi)存地址即可，如果需要還可以對(duì)內(nèi)存塊數(shù)據(jù)清零。

當(dāng)span內(nèi)的所有內(nèi)存塊都被占用時(shí)，沒有剩余空間繼續(xù)分配對(duì)象，mcache會(huì)向mcentral申請(qǐng)1個(gè)span，mcache拿到span后繼續(xù)分配對(duì)象。

• mcache向mcentral申請(qǐng)span

mcentral和mcache一樣，都是0~133這134個(gè)span class級(jí)別，但每個(gè)級(jí)別都保存了2個(gè)span list，即2個(gè)span鏈表：

• nonempty：這個(gè)鏈表里的span，所有span都至少有1個(gè)空閑的對(duì)象空間。這些span是mcache釋放span時(shí)加入到該鏈表的。
• empty：這個(gè)鏈表里的span，所有的span都不確定里面是否有空閑的對(duì)象空間。當(dāng)一個(gè)span交給mcache的時(shí)候，就會(huì)加入到empty鏈表。

這兩個(gè)東西名稱一直有點(diǎn)繞，建議直接把empty理解為沒有對(duì)象空間就好了。

mcache向mcentral申請(qǐng)span時(shí)，mcentral會(huì)先從nonempty搜索滿足條件的span，如果沒有找到再從emtpy搜索滿足條件的span，然后把找到的span交給mcache。

• mheap的span管理

mheap里保存了兩棵二叉排序樹，按span的page數(shù)量進(jìn)行排序：

• free：free中保存的span是空閑并且非垃圾回收的span。
• scav：scav中保存的是空閑并且已經(jīng)垃圾回收的span。

如果是垃圾回收導(dǎo)致的span釋放，span會(huì)被加入到scav，否則加入到free，比如剛從OS申請(qǐng)的的內(nèi)存也組成的Span。

mheap中還有arenas，由一組heapArena組成，每一個(gè)heapArena都包含了連續(xù)的pagesPerArena個(gè)span，這個(gè)主要是為mheap管理span和垃圾回收服務(wù)。mheap本身是一個(gè)全局變量，它里面的數(shù)據(jù)，也都是從OS直接申請(qǐng)來的內(nèi)存，并不在mheap所管理的那部分內(nèi)存以內(nèi)。

• mcentral向mheap申請(qǐng)span

當(dāng)mcentral向mcache提供span時(shí)，如果empty里也沒有符合條件的span，mcentral會(huì)向mheap申請(qǐng)span。

此時(shí)，mcentral需要向mheap提供需要的內(nèi)存頁數(shù)和span class級(jí)別，然后它優(yōu)先從free中搜索可用的span。如果沒有找到，會(huì)從scav中搜索可用的span。如果還沒有找到，它會(huì)向OS申請(qǐng)內(nèi)存，再重新搜索2棵樹，必然能找到span。如果找到的span比需要的span大，則把span進(jìn)行分割成2個(gè)span，其中1個(gè)剛好是需求大小，把剩下的span再加入到free中去，然后設(shè)置需要的span的基本信息，然后交給mcentral。

• mheap向OS申請(qǐng)內(nèi)存

當(dāng)mheap沒有足夠的內(nèi)存時(shí)，mheap會(huì)向OS申請(qǐng)內(nèi)存，把申請(qǐng)的內(nèi)存頁保存為span，然后把span插入到free樹。在32位系統(tǒng)中，mheap還會(huì)預(yù)留一部分空間，當(dāng)mheap沒有空間時(shí)，先從預(yù)留空間申請(qǐng)，如果預(yù)留空間內(nèi)存也沒有了，才向OS申請(qǐng)。

3.2. 大對(duì)象的內(nèi)存分配

大對(duì)象的分配比小對(duì)象省事多了，99%的流程與mcentral向mheap申請(qǐng)內(nèi)存的相同，所以不重復(fù)介紹了。不同的一點(diǎn)在于mheap會(huì)記錄一點(diǎn)大對(duì)象的統(tǒng)計(jì)信息，詳情見mheap.alloc_m()。

4. Go垃圾回收和內(nèi)存釋放

如果只申請(qǐng)和分配內(nèi)存，內(nèi)存終將枯竭。Go使用垃圾回收收集不再使用的span，調(diào)用mspan.scavenge()把span釋放還給OS（并非真釋放，只是告訴OS這片內(nèi)存的信息無用了，如果你需要的話，收回去好了），然后交給mheap，mheap對(duì)span進(jìn)行span的合并，把合并后的span加入scav樹中，等待再分配內(nèi)存時(shí)，由mheap進(jìn)行內(nèi)存再分配，Go垃圾回收也是一個(gè)很強(qiáng)的主題，計(jì)劃后面單獨(dú)寫一篇文章介紹。

現(xiàn)在我們關(guān)注一下，Go程序是怎么把內(nèi)存釋放給操作系統(tǒng)的？釋放內(nèi)存的函數(shù)是sysUnused，它會(huì)被mspan.scavenge()調(diào)用:

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 的功能類似，它的功能是給內(nèi)核提供一個(gè)建議：這個(gè)內(nèi)存地址區(qū)間的內(nèi)存已經(jīng)不再使用，可以進(jìn)行回收。但內(nèi)核是否回收，以及什么時(shí)候回收，這就是內(nèi)核的事情了。如果內(nèi)核真把這片內(nèi)存回收了，當(dāng)Go程序再使用這個(gè)地址時(shí)，內(nèi)核會(huì)重新進(jìn)行虛擬地址到物理地址的映射。所以在內(nèi)存充足的情況下，內(nèi)核也沒有必要立刻回收內(nèi)存。

5. Go的棧內(nèi)存

最后提一下棧內(nèi)存。從一個(gè)宏觀的角度看，內(nèi)存管理不應(yīng)當(dāng)只有堆，也應(yīng)當(dāng)有棧。每個(gè)goroutine都有自己的棧，棧的初始大小是2KB，100萬的goroutine會(huì)占用2G，但goroutine的棧會(huì)在2KB不夠用時(shí)自動(dòng)擴(kuò)容，當(dāng)擴(kuò)容為4KB的時(shí)候，百萬goroutine會(huì)占用4GB。

總結(jié)

Go的內(nèi)存分配原理就不再回顧了，它主要強(qiáng)調(diào)兩個(gè)重要的思想：

• 使用緩存提高效率。在存儲(chǔ)的整個(gè)體系中到處可見緩存的思想，Go內(nèi)存分配和管理也使用了緩存，利用緩存一是減少了系統(tǒng)調(diào)用的次數(shù)，二是降低了鎖的粒度、減少加鎖的次數(shù)，從這2點(diǎn)提高了內(nèi)存管理效率。

• 以空間換時(shí)間，提高內(nèi)存管理效率?？臻g換時(shí)間是一種常用的性能優(yōu)化思想，這種思想其實(shí)非常普遍，比如Hash、Map、二叉排序樹等數(shù)據(jù)結(jié)構(gòu)的本質(zhì)就是空間換時(shí)間，在數(shù)據(jù)庫中也很常見，比如數(shù)據(jù)庫索引、索引視圖和數(shù)據(jù)緩存等，再如Redis等緩存數(shù)據(jù)庫也是空間換時(shí)間的思想。

以上就是詳解Go語言的內(nèi)存模型及堆的分配管理的詳細(xì)內(nèi)容，更多關(guān)于Go內(nèi)存模型及堆的分配的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！