golang內存,golang內存模型

本文目錄一覽：

• 1、【golang】內存逃逸常見情況和避免方式
• 2、Golang 1.14中內存分配、清掃和內存回收
• 3、（十一）golang 內存分析
• 4、每天一個知識點：Golang 內存逃逸
• 5、嵌入式golang佔用內存高
• 6、golang內存擴容

【golang】內存逃逸常見情況和避免方式

因為如果變數的內存發生逃逸，它的生命周期就是不可知的，其會被分配到堆上，而堆上分配內存不能像棧一樣會自動釋放，為了解放程序員雙手，專註於業務的實現，go實現了gc垃圾回收機制，但gc會影響程序運行性能，所以要盡量減少程序的gc操作。

1、在方法內把局部變數指針返回，被外部引用，其生命周期大於棧，則溢出。

2、發送指針或帶有指針的值到channel，因為編譯時候無法知道那個goroutine會在channel接受數據，編譯器無法知道什麼時候釋放。

3、在一個切片上存儲指針或帶指針的值。比如[]*string，導致切片內容逃逸，其引用值一直在堆上。

4、因為切片的append導致超出容量，切片重新分配地址，切片背後的存儲基於運行時的數據進行擴充，就會在堆上分配。

5、在interface類型上調用方法，在Interface調用方法是動態調度的，只有在運行時才知道。

1、go語言的介面類型方法調用是動態，因此不能在編譯階段確定，所有類型結構轉換成介面的過程會涉及到內存逃逸發生，在頻次訪問較高的函數盡量調用介面。

2、不要盲目使用變數指針作為參數，雖然減少了複製，但變數逃逸的開銷更大。

3、預先設定好slice長度，避免頻繁超出容量，重新分配。

Golang 1.14中內存分配、清掃和內存回收

Golang的內存分配是由golang runtime完成，其內存分配方案借鑒自tcmalloc。

主要特點就是

本文中的element指一定大小的內存塊是內存分配的概念，並為出現在golang runtime源碼中

本文講述x8664架構下的內存分配

Golang 內存分配有下面幾個主要結構

Tiny對象是指內存尺寸小於16B的對象，這類對象的分配使用mcache的tiny區域進行分配。當tiny區域空間耗盡時刻，它會從mcache.alloc[tinySpanClass]指向的mspan中找到空閑的區域。當然如果mcache中span空間也耗盡，它會觸發從mcentral補充mspan到mcache的流程。

小對象是指對象尺寸在（16B，32KB]之間的對象，這類對象的分配原則是：

1、首先根據對象尺寸將對象歸為某個SpanClass上，這個SpanClass上所有的element都是一個統一的尺寸。

2、從mcache.alloc[SpanClass]找到mspan，看看有無空閑的element，如果有分配成功。如果沒有繼續。

3、從mcentral.allocSpan[SpanClass]的nonempty和emtpy中找到合適的mspan，返回給mcache。如果沒有找到就進入mcentral.grow()—mheap.alloc()分配新的mspan給mcentral。

大對象指尺寸超出32KB的對象，此時直接從mheap中分配，不會走mcache和mcentral，直接走mheap.alloc()分配一個SpanClass==0 的mspan表示這部分分配空間。

對於程序分配常用的tiny和小對象的分配，可以通過無鎖的mcache提升分配性能。mcache不足時刻會拿mcentral的鎖，然後從mcentral中充mspan 給mcache。大對象直接從mheap 中分配。

在x8664環境上，golang管理的有效的程序虛擬地址空間實質上只有48位。在mheap中有一個pages pageAlloc成員用於管理golang堆內存的地址空間。golang從os中申請地址空間給自己管理，地址空間申請下來以後，golang會將地址空間根據實際使用情況標記為free或者alloc。如果地址空間被分配給mspan或大對象後，那麼被標記為alloc，反之就是free。

Golang認為地址空間有以下4種狀態：

Golang同時定義了下面幾個地址空間操作函數：

在mheap結構中，有一個名為pages成員，它用於golang 堆使用虛擬地址空間進行管理。其類型為pageAlloc

pageAlloc 結構表示的golang 堆的所有地址空間。其中最重要的成員有兩個：

在golang的gc流程中會將未使用的對象標記為未使用，但是這些對象所使用的地址空間並未交還給os。地址空間的申請和釋放都是以golang的page為單位（實際以chunk為單位）進行的。sweep的最終結果只是將某個地址空間標記可被分配，並未真正釋放地址空間給os，真正釋放是後文的scavenge過程。

在gc mark結束以後會使用sweep()去嘗試free一個span；在mheap.alloc 申請mspan時刻，也使用sweep去清掃一下。

清掃mspan主要涉及到下面函數

如上節所述，sweep只是將page標記為可分配，但是並未把地址空間釋放；真正的地址空間釋放是scavenge過程。

真正的scavenge是由pageAlloc.scavenge()—sysUnused()將掃描到待釋放的chunk所表示的地址空間釋放掉（使用sysUnused()將地址空間還給os）

golang的scavenge過程有兩種：

（十一）golang 內存分析

編寫過C語言程序的肯定知道通過malloc()方法動態申請內存，其中內存分配器使用的是glibc提供的ptmalloc2。 除了glibc，業界比較出名的內存分配器有Google的tcmalloc和Facebook的jemalloc。二者在避免內存碎片和性能上均比glic有比較大的優勢，在多線程環境中效果更明顯。

Golang中也實現了內存分配器，原理與tcmalloc類似，簡單的說就是維護一塊大的全局內存，每個線程(Golang中為P)維護一塊小的私有內存，私有內存不足再從全局申請。另外，內存分配與GC（垃圾回收）關係密切，所以了解GC前有必要了解內存分配的原理。

為了方便自主管理內存，做法便是先向系統申請一塊內存，然後將內存切割成小塊，通過一定的內存分配演算法管理內存。 以64位系統為例，Golang程序啟動時會向系統申請的內存如下圖所示：

預申請的內存劃分為spans、bitmap、arena三部分。其中arena即為所謂的堆區，應用中需要的內存從這裡分配。其中spans和bitmap是為了管理arena區而存在的。

arena的大小為512G，為了方便管理把arena區域劃分成一個個的page，每個page為8KB,一共有512GB/8KB個頁；

spans區域存放span的指針，每個指針對應一個page，所以span區域的大小為(512GB/8KB)乘以指針大小8byte = 512M

bitmap區域大小也是通過arena計算出來，不過主要用於GC。

span是用於管理arena頁的關鍵數據結構，每個span中包含1個或多個連續頁，為了滿足小對象分配，span中的一頁會劃分更小的粒度，而對於大對象比如超過頁大小，則通過多頁實現。

根據對象大小，劃分了一系列class，每個class都代表一個固定大小的對象，以及每個span的大小。如下表所示：

上表中每列含義如下：

class： class ID，每個span結構中都有一個class ID, 表示該span可處理的對象類型

bytes/obj：該class代表對象的位元組數

bytes/span：每個span佔用堆的位元組數，也即頁數乘以頁大小

objects: 每個span可分配的對象個數，也即（bytes/spans）/（bytes/obj）waste

bytes: 每個span產生的內存碎片，也即（bytes/spans）%（bytes/obj）上表可見最大的對象是32K大小，超過32K大小的由特殊的class表示，該class ID為0，每個class只包含一個對象。

span是內存管理的基本單位,每個span用於管理特定的class對象, 跟據對象大小，span將一個或多個頁拆分成多個塊進行管理。src/runtime/mheap.go:mspan定義了其數據結構：

以class 10為例，span和管理的內存如下圖所示：

spanclass為10，參照class表可得出npages=1,nelems=56,elemsize為144。其中startAddr是在span初始化時就指定了某個頁的地址。allocBits指向一個點陣圖，每位代表一個塊是否被分配，本例中有兩個塊已經被分配，其allocCount也為2。next和prev用於將多個span鏈接起來，這有利於管理多個span，接下來會進行說明。

有了管理內存的基本單位span，還要有個數據結構來管理span，這個數據結構叫mcentral，各線程需要內存時從mcentral管理的span中申請內存，為了避免多線程申請內存時不斷的加鎖，Golang為每個線程分配了span的緩存，這個緩存即是cache。src/runtime/mcache.go:mcache定義了cache的數據結構

alloc為mspan的指針數組，數組大小為class總數的2倍。數組中每個元素代表了一種class類型的span列表，每種class類型都有兩組span列表，第一組列表中所表示的對象中包含了指針，第二組列表中所表示的對象不含有指針，這麼做是為了提高GC掃描性能，對於不包含指針的span列表，沒必要去掃描。根據對象是否包含指針，將對象分為noscan和scan兩類，其中noscan代表沒有指針，而scan則代表有指針，需要GC進行掃描。mcache和span的對應關係如下圖所示：

mchache在初始化時是沒有任何span的，在使用過程中會動態的從central中獲取並緩存下來，跟據使用情況，每種class的span個數也不相同。上圖所示，class 0的span數比class1的要多，說明本線程中分配的小對象要多一些。

cache作為線程的私有資源為單個線程服務，而central則是全局資源，為多個線程服務，當某個線程內存不足時會向central申請，當某個線程釋放內存時又會回收進central。src/runtime/mcentral.go:mcentral定義了central數據結構：

lock: 線程間互斥鎖，防止多線程讀寫衝突

spanclass : 每個mcentral管理著一組有相同class的span列表

nonempty: 指還有內存可用的span列表

empty: 指沒有內存可用的span列表

nmalloc: 指累計分配的對象個數線程從central獲取span步驟如下：

將span歸還步驟如下：

從mcentral數據結構可見，每個mcentral對象只管理特定的class規格的span。事實上每種class都會對應一個mcentral,這個mcentral的集合存放於mheap數據結構中。src/runtime/mheap.go:mheap定義了heap的數據結構：

lock： 互斥鎖

spans: 指向spans區域，用於映射span和page的關係

bitmap：bitmap的起始地址

arena_start: arena區域首地址

arena_used: 當前arena已使用區域的最大地址

central: 每種class對應的兩個mcentral

從數據結構可見，mheap管理著全部的內存，事實上Golang就是通過一個mheap類型的全局變數進行內存管理的。mheap內存管理示意圖如下：

系統預分配的內存分為spans、bitmap、arean三個區域，通過mheap管理起來。接下來看內存分配過程。

針對待分配對象的大小不同有不同的分配邏輯：

(0, 16B) 且不包含指針的對象： Tiny分配

(0, 16B) 包含指針的對象：正常分配

[16B, 32KB] : 正常分配

(32KB, -) : 大對象分配其中Tiny分配和大對象分配都屬於內存管理的優化範疇，這裡暫時僅關注一般的分配方法。

以申請size為n的內存為例，分配步驟如下：

Golang內存分配是個相當複雜的過程，其中還摻雜了GC的處理，這裡僅僅對其關鍵數據結構進行了說明，了解其原理而又不至於深陷實現細節。1、Golang程序啟動時申請一大塊內存並劃分成spans、bitmap、arena區域

2、arena區域按頁劃分成一個個小塊。

3、span管理一個或多個頁。

4、mcentral管理多個span供線程申請使用

5、mcache作為線程私有資源，資源來源於mcentral。

每天一個知識點：Golang 內存逃逸

在程序中，每個函數塊都會有自己的內存區域用來存自己的局部變數（內存佔用少）、返回地址、返回值之類的數據，這一塊內存區域有特定的結構和定址方式，定址起來十分迅速，開銷很少。這一塊內存地址稱為棧。棧是線程級別的，大小在創建的時候已經確定，當變數太大的時候，會”逃逸”到堆上，這種現象稱為內存逃逸。簡單來說，局部變數通過堆分配和回收，就叫內存逃逸。

如果一個函數返回對一個變數的引用，那麼它就會發生逃逸。即任何時候，一個值被分享到函數棧範圍之外，它都會在堆上被重新分配。在這裡有一個例外，就是如果編譯器可以證明在函數返回後不會再被引用的，那麼就會分配到棧上，這個證明的過程叫做逃逸分析。

堆是一塊沒有特定結構，也沒有固定大小的內存區域，可以根據需要進行調整。全局變數，內存佔用較大的局部變數，函數調用結束後不能立刻回收的局部變數都會存在堆裡面。變數在堆上的分配和回收都比在棧上開銷大的多。對於 go 這種帶 GC 的語言來說，會增加 gc 壓力，同時也容易造成內存碎片(採用分區式存儲管理的系統，在儲存分配過程中產生的、不能供用戶作業使用的主存里的小分區稱成「內存碎片」。內存碎片分為內部碎片和外部碎片)。

簡單聊聊內存逃逸 ｜ 劍指offer – golang

Golang內存逃逸是什麼？怎麼避免內存逃逸？

嵌入式golang佔用內存高

嵌入式golang佔用內存高可能問題在於緩存。

清空日誌後比較驚喜地發現，內存瞬間暴降至20M。

嵌入式系統由硬體和軟體組成．是能夠獨立進行運作的器件。其軟體內容只包括軟體運行環境及其操作系統。硬體內容包括信號處理器、存儲器、通信模塊等在內的多方面的內容。相比於一般的計算機處理系統而言，嵌入式系統存在較大的差異性，它不能實現大容量的存儲功能，因為沒有與之相匹配的大容量介質，大部分採用的存儲介質有E-PROM、EEPROM等，軟體部分以API編程介面作為開發平台的核心。嵌入式系統最核心的層次是中央處理單元部分，它包含運算器和控制器模塊，在cpu的基礎上進一步配上存儲器模塊、電源模塊、複位模塊等就構成了通常所說的最小系統。由於技術的進步，集成電路生產商通常會把許多外設做進同一個集成電路中，這樣在使用上更加方便，這樣一個晶元通常稱之為微控制器。在微控制器的基礎上進一步擴展電源感測與檢測、執行器模塊以及配套軟體並構成一個具有特定功能的完整單元，就稱之為一個嵌入式系統或嵌入式應用。

golang內存擴容

一般來說當內存空間span不足時，需要進行擴容。而在擴容前需要將當前沒有剩餘空間的內存塊相關狀態解除，以便後續的垃圾回收期能夠進行掃描和回收，接著在從中間部件(central)提取新的內存塊放回數組中。

需要注意由於中間部件有scan和noscan兩種類型，則申請的內存空間最終獲取的可能是其兩倍，並由heap堆進行統一管理。中間部件central是通過兩個鏈表來管理其分配的所有內存塊：

1、empty代表「無法使用」狀態，沒有剩餘的空間或被移交給緩存的內存塊

2、noempty代表剩餘的空間，並這些內存塊能夠提供服務

由於golang垃圾回收器使用的累增計數器(heap.sweepgen)來表達代齡的：

從上面內容可以看到每次進行清理操作時 該計數器 +2

再來看下mcentral的構成

當通過mcentral進行空間span獲取時，第一步需要到noempty列表檢查剩餘空間的內存塊，這裡面有一點需要說明主要是垃圾回收器的掃描過程和清理過程是同時進行的，那麼為了獲取更多的可用空間，則會在將分配的內存塊移交給cache部件前，先完成清理的操作。第二步當noempty沒有返回時，則需要檢查下empty列表(由於empty里的內存塊有可能已被標記為垃圾，這樣可以直接清理，對應的空間則可直接使用了)。第三步若是noempty和empty都沒有申請到，這時需要堆進行申請內存的

通過上面的源碼也可以看到中間部件central自身擴容操作與大對象內存分配差不多類似。

在golang中將長度小於16bytes的對象稱為微小對象(tiny)，最常見的就是小字元串，一般會將這些微小對象組合起來，並用單塊內存存儲，這樣能夠有效的減少內存浪費。

當微小對象需要分配空間span，首先緩存部件會按指定的規格(tiny size class)取出一塊內存，若容量不足，則重新提取一塊；前面也提到會將微小對象進行組合，而這些組合的微小對象是不能包含指針的，因為垃圾回收的原因，一般都是當前存儲單元里所有的微小對象都不可達時，才會將該塊內存進行回收。

而當從緩衝部件cache中獲取空間span時， 是通過偏移位置(tinyoffset)先來判斷剩餘空間是否滿足需求。若是可以的話則以此計算並返回內存地址；若是空間不足，則提取新的內存塊，直接返回起始地址便可； 最後在對比新舊兩塊內存，空間大的那塊則會被保留。