十年網(wǎng)站開發(fā)經(jīng)驗 + 多家企業(yè)客戶 + 靠譜的建站團隊
量身定制 + 運營維護+專業(yè)推廣+無憂售后,網(wǎng)站問題一站解決
Go 語言較之 C 語言一個很大的優(yōu)勢就是自帶 GC 功能,可 GC 并不是沒有代價的。寫 C 語言的時候,在一個函數(shù)內(nèi)聲明的變量,在函數(shù)退出后會自動釋放掉,因為這些變量分配在棧上。如果你期望變量的數(shù)據(jù)可以在函數(shù)退出后仍然能被訪問,就需要調(diào)用 malloc 方法在堆上申請內(nèi)存,如果程序不再需要這塊內(nèi)存了,再調(diào)用 free 方法釋放掉。Go 語言不需要你主動調(diào)用 malloc 來分配堆空間,編譯器會自動分析,找出需要 malloc 的變量,使用堆內(nèi)存。編譯器的這個分析過程就叫做逃逸分析。
南潯ssl適用于網(wǎng)站、小程序/APP、API接口等需要進行數(shù)據(jù)傳輸應用場景,ssl證書未來市場廣闊!成為創(chuàng)新互聯(lián)的ssl證書銷售渠道,可以享受市場價格4-6折優(yōu)惠!如果有意向歡迎電話聯(lián)系或者加微信:18982081108(備注:SSL證書合作)期待與您的合作!
所以你在一個函數(shù)中通過 dict := make(map[string]int) 創(chuàng)建一個 map 變量,其背后的數(shù)據(jù)是放在棧空間上還是堆空間上,是不一定的。這要看編譯器分析的結(jié)果。
可逃逸分析并不是百分百準確的,它有缺陷。有的時候你會發(fā)現(xiàn)有些變量其實在??臻g上分配完全沒問題的,但編譯后程序還是把這些數(shù)據(jù)放在了堆上。如果你了解 Go 語言編譯器逃逸分析的機制,在寫代碼的時候就可以有意識地繞開這些缺陷,使你的程序更高效。
Go 語言雖然在內(nèi)存管理方面降低了編程門檻,即使你不了解堆棧也能正常開發(fā),但如果你要在性能上較真的話,還是要掌握這些基礎知識。
這里不對堆內(nèi)存和棧內(nèi)存的區(qū)別做太多闡述。簡單來說就是, 棧分配廉價,堆分配昂貴。 ??臻g會隨著一個函數(shù)的結(jié)束自動釋放,堆空間需要時間 GC 模塊不斷地跟蹤掃描回收。如果對這兩個概念有些迷糊,建議閱讀下面 2 個文章:
這里舉一個小例子,來對比下堆棧的差別:
stack 函數(shù)中的變量 i 在函數(shù)退出會自動釋放;而 heap 函數(shù)返回的是對變量 i 的引用,也就是說 heap() 退出后,表示變量 i 還要能被訪問,它會自動被分配到堆空間上。
他們編譯出來的代碼如下:
邏輯的復雜度不言而喻,從上面的匯編中可看到, heap() 函數(shù)調(diào)用了 runtime.newobject() 方法,它會調(diào)用 mallocgc 方法從 mcache 上申請內(nèi)存,申請的內(nèi)部邏輯前面文章已經(jīng)講述過。堆內(nèi)存分配不僅分配上邏輯比??臻g分配復雜,它最致命的是會帶來很大的管理成本,Go 語言要消耗很多的計算資源對其進行標記回收(也就是 GC 成本)。
Go 編輯器會自動幫我們找出需要進行動態(tài)分配的變量,它是在編譯時追蹤一個變量的生命周期,如果能確認一個數(shù)據(jù)只在函數(shù)空間內(nèi)訪問,不會被外部使用,則使用??臻g,否則就要使用堆空間。
我們在 go build 編譯代碼時,可使用 -gcflags '-m' 參數(shù)來查看逃逸分析日志。
以上面的兩個函數(shù)為例,編譯的日志輸出是:
日志中的 i escapes to heap 表示該變量數(shù)據(jù)逃逸到了堆上。
需要使用堆空間,所以逃逸,這沒什么可爭議的。但編譯器有時會將 不需要 使用堆空間的變量,也逃逸掉。這里是容易出現(xiàn)性能問題的大坑。網(wǎng)上有很多相關文章,列舉了一些導致逃逸情況,其實總結(jié)起來就一句話:
多級間接賦值容易導致逃逸 。
這里的多級間接指的是,對某個引用類對象中的引用類成員進行賦值。Go 語言中的引用類數(shù)據(jù)類型有 func , interface , slice , map , chan , *Type(指針) 。
記住公式 Data.Field = Value ,如果 Data , Field 都是引用類的數(shù)據(jù)類型,則會導致 Value 逃逸。這里的等號 = 不單單只賦值,也表示參數(shù)傳遞。
根據(jù)公式,我們假設一個變量 data 是以下幾種類型,相應的可以得出結(jié)論:
下面給出一些實際的例子:
如果變量值是一個函數(shù),函數(shù)的參數(shù)又是引用類型,則傳遞給它的參數(shù)都會逃逸。
上例中 te 的類型是 func(*int) ,屬于引用類型,參數(shù) *int 也是引用類型,則調(diào)用 te(j) 形成了為 te 的參數(shù)(成員) *int 賦值的現(xiàn)象,即 te.i = j 會導致逃逸。代碼中其他幾種調(diào)用都沒有形成 多級間接賦值 情況。
同理,如果函數(shù)的參數(shù)類型是 slice , map 或 interface{} 都會導致參數(shù)逃逸。
匿名函數(shù)的調(diào)用也是一樣的,它本質(zhì)上也是一個函數(shù)變量。有興趣的可以自己測試一下。
只要使用了 Interface 類型(不是 interafce{} ),那么賦值給它的變量一定會逃逸。因為 interfaceVariable.Method() 先是間接的定位到它的實際值,再調(diào)用實際值的同名方法,執(zhí)行時實際值作為參數(shù)傳遞給方法。相當于 interfaceVariable.Method.this = realValue
向 channel 中發(fā)送數(shù)據(jù),本質(zhì)上就是為 channel 內(nèi)部的成員賦值,就像給一個 slice 中的某一項賦值一樣。所以 chan *Type , chan map[Type]Type , chan []Type , chan interface{} 類型都會導致發(fā)送到 channel 中的數(shù)據(jù)逃逸。
這本來也是情理之中的,發(fā)送給 channel 的數(shù)據(jù)是要與其他函數(shù)分享的,為了保證發(fā)送過去的指針依然可用,只能使用堆分配。
可變參數(shù)如 func(arg ...string) 實際與 func(arg []string) 是一樣的,會增加一層訪問路徑。這也是 fmt.Sprintf 總是會使參數(shù)逃逸的原因。
例子非常多,這里不能一一列舉,我們只需要記住分析方法就好,即,2 級或更多級的訪問賦值會 容易 導致數(shù)據(jù)逃逸。這里加上 容易 二字是因為隨著語言的發(fā)展,相信這些問題會被慢慢解決,但現(xiàn)階段,這個可以作為我們分析逃逸現(xiàn)象的依據(jù)。
下面代碼中包含 2 種很常規(guī)的寫法,但他們卻有著很大的性能差距,建議自己想下為什么。
Benchmark 和 pprof 給出的結(jié)果:
熟悉堆棧概念可以讓我們更容易看透 Go 程序的性能問題,并進行優(yōu)化。
多級間接賦值會導致 Go 編譯器出現(xiàn)不必要的逃逸,在一些情況下可能我們只需要修改一下數(shù)據(jù)結(jié)構(gòu)就會使性能有大幅提升。這也是很多人不推薦在 Go 中使用指針的原因,因為它會增加一級訪問路徑,而 map , slice , interface{} 等類型是不可避免要用到的,為了減少不必要的逃逸,只能拿指針開刀了。
大多數(shù)情況下,性能優(yōu)化都會為程序帶來一定的復雜度。建議實際項目中還是怎么方便怎么寫,功能完成后通過性能分析找到瓶頸所在,再對局部進行優(yōu)化。
在Golang語言開發(fā)過程中,我們經(jīng)常會用到數(shù)組和切片數(shù)據(jù)結(jié)構(gòu),數(shù)組是固定長度的,而切片是可以擴張的數(shù)組,那么切片底層到底有什么不同?接下來我們來詳細分析一下內(nèi)部實現(xiàn)。
首先我們來看一下數(shù)據(jù)結(jié)構(gòu)
這里的array其實是指向切片管理的內(nèi)存塊首地址,而len就是切片的實際使用大小,cap就是切片的容量。
我們可以通過下面的代碼輸出slice:
這么分析下來,我們可以了解如下內(nèi)容:
使用一個切片通常有兩種方法:
另一種是slice = make([]int, len, cap)這種方法,稱為分配內(nèi)存。
創(chuàng)建一個slice,實質(zhì)上是在分配內(nèi)存。
這里跟一下細節(jié),math.MulUintptr是基于底層的指針計算乘法的,這樣計算不會導致超出int大小,這個方法在后面會經(jīng)常用到。
同樣,對于int64的長度,也有對應的方法
而實際分配內(nèi)存的操作調(diào)用mallocgc這個分配內(nèi)存的函數(shù),這個函數(shù)以后再分析。
我們了解切片和數(shù)組最大的不同就是切片能夠自動擴容,接下來看看切片是如何擴容的
這里可以看到,growslice是返回了一個新的slice,也就是說如果發(fā)生了擴容,會發(fā)生拷貝。
所以我們在使用過程中,如果預先知道容量,可以預先分配好容量再使用,能提高運行效率。
copy這個函數(shù)在內(nèi)部實現(xiàn)為slicecopy
還有關于字符串的拷貝
這里顯示了可以把string拷貝成[]byte,不能把[]byte拷貝成string。
1、切片的數(shù)據(jù)結(jié)構(gòu)是 array內(nèi)存地址,len長度,cap容量
2、make的時候需要注意 容量 * 長度 分配的內(nèi)存大小要小于264,并且要小于可分配的內(nèi)存量,同時長度不能大于容量。
3、內(nèi)存增長的過程:
4、當發(fā)生內(nèi)存擴容時,會發(fā)生拷貝數(shù)據(jù)的現(xiàn)象,影響程序運行的效率,如果可以,要先分配好指定的容量
5、關于拷貝,可以把string拷貝成[]byte,不能把[]byte拷貝成string。
編寫過C語言程序的肯定知道通過malloc()方法動態(tài)申請內(nèi)存,其中內(nèi)存分配器使用的是glibc提供的ptmalloc2。 除了glibc,業(yè)界比較出名的內(nèi)存分配器有Google的tcmalloc和Facebook的jemalloc。二者在避免內(nèi)存碎片和性能上均比glic有比較大的優(yōu)勢,在多線程環(huán)境中效果更明顯。
Golang中也實現(xiàn)了內(nèi)存分配器,原理與tcmalloc類似,簡單的說就是維護一塊大的全局內(nèi)存,每個線程(Golang中為P)維護一塊小的私有內(nèi)存,私有內(nèi)存不足再從全局申請。另外,內(nèi)存分配與GC(垃圾回收)關系密切,所以了解GC前有必要了解內(nèi)存分配的原理。
為了方便自主管理內(nèi)存,做法便是先向系統(tǒng)申請一塊內(nèi)存,然后將內(nèi)存切割成小塊,通過一定的內(nèi)存分配算法管理內(nèi)存。 以64位系統(tǒng)為例,Golang程序啟動時會向系統(tǒng)申請的內(nèi)存如下圖所示:
預申請的內(nèi)存劃分為spans、bitmap、arena三部分。其中arena即為所謂的堆區(qū),應用中需要的內(nèi)存從這里分配。其中spans和bitmap是為了管理arena區(qū)而存在的。
arena的大小為512G,為了方便管理把arena區(qū)域劃分成一個個的page,每個page為8KB,一共有512GB/8KB個頁;
spans區(qū)域存放span的指針,每個指針對應一個page,所以span區(qū)域的大小為(512GB/8KB)乘以指針大小8byte = 512M
bitmap區(qū)域大小也是通過arena計算出來,不過主要用于GC。
span是用于管理arena頁的關鍵數(shù)據(jù)結(jié)構(gòu),每個span中包含1個或多個連續(xù)頁,為了滿足小對象分配,span中的一頁會劃分更小的粒度,而對于大對象比如超過頁大小,則通過多頁實現(xiàn)。
根據(jù)對象大小,劃分了一系列class,每個class都代表一個固定大小的對象,以及每個span的大小。如下表所示:
上表中每列含義如下:
class: class ID,每個span結(jié)構(gòu)中都有一個class ID, 表示該span可處理的對象類型
bytes/obj:該class代表對象的字節(jié)數(shù)
bytes/span:每個span占用堆的字節(jié)數(shù),也即頁數(shù)乘以頁大小
objects: 每個span可分配的對象個數(shù),也即(bytes/spans)/(bytes/obj)waste
bytes: 每個span產(chǎn)生的內(nèi)存碎片,也即(bytes/spans)%(bytes/obj)上表可見最大的對象是32K大小,超過32K大小的由特殊的class表示,該class ID為0,每個class只包含一個對象。
span是內(nèi)存管理的基本單位,每個span用于管理特定的class對象, 跟據(jù)對象大小,span將一個或多個頁拆分成多個塊進行管理。src/runtime/mheap.go:mspan定義了其數(shù)據(jù)結(jié)構(gòu):
以class 10為例,span和管理的內(nèi)存如下圖所示:
spanclass為10,參照class表可得出npages=1,nelems=56,elemsize為144。其中startAddr是在span初始化時就指定了某個頁的地址。allocBits指向一個位圖,每位代表一個塊是否被分配,本例中有兩個塊已經(jīng)被分配,其allocCount也為2。next和prev用于將多個span鏈接起來,這有利于管理多個span,接下來會進行說明。
有了管理內(nèi)存的基本單位span,還要有個數(shù)據(jù)結(jié)構(gòu)來管理span,這個數(shù)據(jù)結(jié)構(gòu)叫mcentral,各線程需要內(nèi)存時從mcentral管理的span中申請內(nèi)存,為了避免多線程申請內(nèi)存時不斷的加鎖,Golang為每個線程分配了span的緩存,這個緩存即是cache。src/runtime/mcache.go:mcache定義了cache的數(shù)據(jù)結(jié)構(gòu)
alloc為mspan的指針數(shù)組,數(shù)組大小為class總數(shù)的2倍。數(shù)組中每個元素代表了一種class類型的span列表,每種class類型都有兩組span列表,第一組列表中所表示的對象中包含了指針,第二組列表中所表示的對象不含有指針,這么做是為了提高GC掃描性能,對于不包含指針的span列表,沒必要去掃描。根據(jù)對象是否包含指針,將對象分為noscan和scan兩類,其中noscan代表沒有指針,而scan則代表有指針,需要GC進行掃描。mcache和span的對應關系如下圖所示:
mchache在初始化時是沒有任何span的,在使用過程中會動態(tài)的從central中獲取并緩存下來,跟據(jù)使用情況,每種class的span個數(shù)也不相同。上圖所示,class 0的span數(shù)比class1的要多,說明本線程中分配的小對象要多一些。
cache作為線程的私有資源為單個線程服務,而central則是全局資源,為多個線程服務,當某個線程內(nèi)存不足時會向central申請,當某個線程釋放內(nèi)存時又會回收進central。src/runtime/mcentral.go:mcentral定義了central數(shù)據(jù)結(jié)構(gòu):
lock: 線程間互斥鎖,防止多線程讀寫沖突
spanclass : 每個mcentral管理著一組有相同class的span列表
nonempty: 指還有內(nèi)存可用的span列表
empty: 指沒有內(nèi)存可用的span列表
nmalloc: 指累計分配的對象個數(shù)線程從central獲取span步驟如下:
將span歸還步驟如下:
從mcentral數(shù)據(jù)結(jié)構(gòu)可見,每個mcentral對象只管理特定的class規(guī)格的span。事實上每種class都會對應一個mcentral,這個mcentral的集合存放于mheap數(shù)據(jù)結(jié)構(gòu)中。src/runtime/mheap.go:mheap定義了heap的數(shù)據(jù)結(jié)構(gòu):
lock: 互斥鎖
spans: 指向spans區(qū)域,用于映射span和page的關系
bitmap:bitmap的起始地址
arena_start: arena區(qū)域首地址
arena_used: 當前arena已使用區(qū)域的最大地址
central: 每種class對應的兩個mcentral
從數(shù)據(jù)結(jié)構(gòu)可見,mheap管理著全部的內(nèi)存,事實上Golang就是通過一個mheap類型的全局變量進行內(nèi)存管理的。mheap內(nèi)存管理示意圖如下:
系統(tǒng)預分配的內(nèi)存分為spans、bitmap、arean三個區(qū)域,通過mheap管理起來。接下來看內(nèi)存分配過程。
針對待分配對象的大小不同有不同的分配邏輯:
(0, 16B) 且不包含指針的對象: Tiny分配
(0, 16B) 包含指針的對象:正常分配
[16B, 32KB] : 正常分配
(32KB, -) : 大對象分配其中Tiny分配和大對象分配都屬于內(nèi)存管理的優(yōu)化范疇,這里暫時僅關注一般的分配方法。
以申請size為n的內(nèi)存為例,分配步驟如下:
Golang內(nèi)存分配是個相當復雜的過程,其中還摻雜了GC的處理,這里僅僅對其關鍵數(shù)據(jù)結(jié)構(gòu)進行了說明,了解其原理而又不至于深陷實現(xiàn)細節(jié)。1、Golang程序啟動時申請一大塊內(nèi)存并劃分成spans、bitmap、arena區(qū)域
2、arena區(qū)域按頁劃分成一個個小塊。
3、span管理一個或多個頁。
4、mcentral管理多個span供線程申請使用
5、mcache作為線程私有資源,資源來源于mcentral。
malloc申請的空間是在"堆"上的
平時我們都是用聲明變量來申請空間的,此時申請到的空間是"棧"上的
棧上的空間, 不需要程序員負責釋放.
例如,在以下函數(shù)中
int go() {
int a;
int b[50];
}
在運行到go里面時, 申請了4個字節(jié)(int類型是4個字節(jié))的空間來放變量a, 4*50=200個字節(jié)的空間來放變量數(shù)組b
在調(diào)用go時
// ...
go();
// ...
在運行到go()函數(shù)的里部,會申請相應的空間,但在退出go()以后,這些空間就會被廢棄.
這在有些時候不能夠滿足我們的需求,因而就要用到malloc和free
malloc申請的空間,要由我們程序員來負責釋放
int go() {
int* a;
a = malloc(sizeof(int));
}
這樣就在堆上申請到了4個字節(jié)的空間了(sizeof(int)能夠得到int的大小, 返回4).
我們還可以
int* a;
a = malloc(100 * sizeof(int))
來申請到100個int的空間.
退出go以后,空間不會釋放.所以要用free來釋放.
:)