英文原文鏈接【Go, the unwritten parts】 發(fā)表于2017/05/22 作者JBD是Go語言開發(fā)小組成員
10年積累的網(wǎng)站建設(shè)、網(wǎng)站制作經(jīng)驗，可以快速應(yīng)對客戶對網(wǎng)站的新想法和需求。提供各種問題對應(yīng)的解決方案。讓選擇我們的客戶得到更好、更有力的網(wǎng)絡(luò)服務(wù)。我雖然不認(rèn)識你，你也不認(rèn)識我。但先網(wǎng)站制作后付款的網(wǎng)站建設(shè)流程，更有鄖西免費網(wǎng)站建設(shè)讓你可以放心的選擇與我們合作。
檢查程序的執(zhí)行路徑和當(dāng)前狀態(tài)是非常有用的調(diào)試手段。核心文件（core file）包含了一個運行進(jìn)程的內(nèi)存轉(zhuǎn)儲和狀態(tài)。它主要是用來作為事后調(diào)試程序用的。它也可以被用來查看一個運行中的程序的狀態(tài)。這兩個使用場景使調(diào)試文件轉(zhuǎn)儲成為一個非常好的診斷手段。我們可以用這個方法來做事后診斷和分析線上的服務(wù)（production services）。
在這篇文章中，我們將用一個簡單的hello world網(wǎng)站服務(wù)作為例子。在現(xiàn)實中，我們的程序很容易就會變得很復(fù)雜。分析核心轉(zhuǎn)儲給我們提供了一個機(jī)會去重構(gòu)程序的狀態(tài)并且查看只有在某些條件／環(huán)境下才能重現(xiàn)的案例。
作者注 : 這個調(diào)試流程只在Linux上可行。我不是很確定它是否在其它Unixs系統(tǒng)上工作。macOS對此還不支持。Windows現(xiàn)在也不支持。
在我們開始前，需要確保核心轉(zhuǎn)儲的ulimit設(shè)置在合適的范圍。它的缺省值是0，意味著最大的核心文件大小是0。我通常在我的開發(fā)機(jī)器上將它設(shè)置成unlimited。使用以下命令：
接下來，你需要在你的機(jī)器上安裝 delve 。
下面我們使用的 main.go 文件。它注冊了一個簡單的請求處理函數(shù)（handler）然后啟動了HTTP服務(wù)。
讓我們編譯并生產(chǎn)二進(jìn)制文件。
現(xiàn)在讓我們假設(shè)，這個服務(wù)器出了些問題，但是我們并不是很確定問題的根源。你可能已經(jīng)在程序里加了很多輔助信息，但還是無法從這些調(diào)試信息中找出線索。通常在這種情況下，當(dāng)前進(jìn)程的快照會非常有用。我們可以用這個快照深入查看程序的當(dāng)前狀態(tài)。
有幾個方式來獲取核心文件。你可能已經(jīng)熟悉了奔潰轉(zhuǎn)儲（crash dumps）。它們是在一個程序奔潰的時候?qū)懭氪疟P的核心轉(zhuǎn)儲。Go語言在缺省設(shè)置下不會生產(chǎn)奔潰轉(zhuǎn)儲。但是當(dāng)你把 GOTRACEBACK 環(huán)境變量設(shè)置成“crash”，你就可以用 Ctrl+backslash 才觸發(fā)奔潰轉(zhuǎn)儲。如下圖所示：
上面的操作會使程序終止，將堆棧跟蹤（stack trace）打印出來，并把核心轉(zhuǎn)儲文件寫入磁盤。
另外個方法可以從一個運行的程序獲得核心轉(zhuǎn)儲而不需要終止相應(yīng)的進(jìn)程。 gcore 可以生產(chǎn)核心文件而無需使運行中的程序退出。
根據(jù)上面的操作，我們獲得了轉(zhuǎn)儲而沒有終止對應(yīng)的進(jìn)程。下一步就是把核心文件加載進(jìn)delve并開始分析。
差不多就這些。delve的常用操作都可以使用。你可以backtrace，list，查看變量等等。有些功能不可用因為我們使用的核心轉(zhuǎn)儲是一個快照而不是正在運行的進(jìn)程。但是程序執(zhí)行路徑和狀態(tài)全部可以訪問。
在Go語言中有一些調(diào)試技巧能幫助我們快速找到問題，有時候你想盡可能多的記錄異常但仍覺得不夠，搞清楚堆棧的意義有助于定位Bug或者記錄更完整的信息。
本文將討論堆棧跟蹤信息以及如何在堆棧中識別函數(shù)所傳遞的參數(shù)。
Functions
先從這段代碼開始：
Listing 1
01 package main
02
03 func main() {
04 ? ? slice := make([]string, 2, 4)
05 ? ? Example(slice, "hello", 10)
06 }
07
08 func Example(slice []string, str string, i int) {
09 ? ? panic("Want stack trace")
10 }
Example函數(shù)定義了3個參數(shù)，1個string類型的slice, 1個string和1個integer, 并且拋出了panic，運行這段代碼可以看到這樣的結(jié)果：
Listing 2
Panic: Want stack trace
goroutine 1 [running]:
main.Example(0x2080c3f50, 0x2, 0x4, 0x425c0, 0x5, 0xa)
/Users/bill/Spaces/Go/Projects/src/github.com/goinaction/code/
temp/main.go:9 +0x64
main.main()
/Users/bill/Spaces/Go/Projects/src/github.com/goinaction/code/
temp/main.go:5 +0x85
goroutine 2 [runnable]:
runtime.forcegchelper()
/Users/bill/go/src/runtime/proc.go:90
runtime.goexit()
/Users/bill/go/src/runtime/asm_amd64.s:2232 +0x1
goroutine 3 [runnable]:
runtime.bgsweep()
/Users/bill/go/src/runtime/mgc0.go:82
runtime.goexit()
/Users/bill/go/src/runtime/asm_amd64.s:2232 +0x1
堆棧信息中顯示了在panic拋出這個時間所有的goroutines狀態(tài)，發(fā)生的panic的goroutine會顯示在最上面。
Listing 3
01 goroutine 1 [running]:
02 main.Example(0x2080c3f50, 0x2, 0x4, 0x425c0, 0x5, 0xa)
/Users/bill/Spaces/Go/Projects/src/github.com/goinaction/code/
temp/main.go:9 +0x64
03 main.main()
/Users/bill/Spaces/Go/Projects/src/github.com/goinaction/code/
temp/main.go:5 +0x85
第1行顯示最先發(fā)出panic的是goroutine 1, 第二行顯示panic位于main.Example中, 并能定位到該行代碼，在本例中第9行引發(fā)了panic。
下面我們關(guān)注參數(shù)是如何傳遞的：
Listing 4
// Declaration
main.Example(slice []string, str string, i int)
// Call to Example by main.
slice := make([]string, 2, 4)
Example(slice, "hello", 10)
// Stack trace
main.Example(0x2080c3f50, 0x2, 0x4, 0x425c0, 0x5, 0xa)
這里展示了在main中帶參數(shù)調(diào)用Example函數(shù)時的堆棧信息，比較就能發(fā)現(xiàn)兩者的參數(shù)數(shù)量并不相同，Example定義了3個參數(shù)，堆棧中顯示了6個參數(shù)。現(xiàn)在的關(guān)鍵問題是我們要弄清楚它們是如何匹配的。
第1個參數(shù)是string類型的slice，我們知道在Go語言中slice是引用類型，即slice變量結(jié)構(gòu)會包含三個部分：指針、長度(Lengthe)、容量(Capacity)
Listing 5
// Slice parameter value
slice := make([]string, 2, 4)
// Slice header values
Pointer: ?0x2080c3f50
Length: ? 0x2
Capacity: 0x4
// Declaration
main.Example(slice []string, str string, i int)
// Stack trace
main.Example(0x2080c3f50, 0x2, 0x4, 0x425c0, 0x5, 0xa)
因此，前面3個參數(shù)會匹配slice， 如下圖所示：
Figure 1
figure provided by Georgi Knox
我們現(xiàn)在來看第二個參數(shù)，它是string類型，string類型也是引用類型，它包括兩部分：指針、長度。
Listing 6
// String parameter value
"hello"
// String header values
Pointer: 0x425c0
Length: ?0x5
// Declaration
main.Example(slice []string,?str string, i int)
// Stack trace
main.Example(0x2080c3f50, 0x2, 0x4,?0x425c0, 0x5, 0xa)
可以確定，堆棧信息中第4、5兩個參數(shù)對應(yīng)代碼中的string參數(shù)，如下圖所示：
Figure 2
figure provided by Georgi Knox
最后一個參數(shù)integer是single word值。
Listing 7
// Integer parameter value
10
// Integer value
Base 16: 0xa
// Declaration
main.Example(slice []string, str string,?i int)
// Stack trace
main.Example(0x2080c3f50, 0x2, 0x4, 0x425c0, 0x5,?0xa)
現(xiàn)在我們可以匹配代碼中的參數(shù)到堆棧信息了。
Figure 3
figure provided by Georgi Knox
Methods
如果我們將Example作為結(jié)構(gòu)體的方法會怎么樣呢?
Listing 8
01 package main
02
03 import "fmt"
04
05 type trace struct{}
06
07 func main() {
08 ? ? slice := make([]string, 2, 4)
09
10 ? ? var t trace
11 ? ? t.Example(slice, "hello", 10)
12 }
13
14 func (t *trace) Example(slice []string, str string, i int) {
15 ? ? fmt.Printf("Receiver Address: %p\n", t)
16 ? ? panic("Want stack trace")
17 }
如上所示修改代碼，將Example定義為trace的方法，并通過trace的實例t來調(diào)用Example。
再次運行程序，會發(fā)現(xiàn)堆棧信息有一點不同：
Listing 9
Receiver Address:?0x1553a8
panic: Want stack trace
01 goroutine 1 [running]:
02 main.(*trace).Example(0x1553a8, 0x2081b7f50, 0x2, 0x4, 0xdc1d0, 0x5, 0xa)
/Users/bill/Spaces/Go/Projects/src/github.com/goinaction/code/
temp/main.go:16 +0x116
03 main.main()
/Users/bill/Spaces/Go/Projects/src/github.com/goinaction/code/
temp/main.go:11 +0xae
首先注意第2行的方法調(diào)用使用了pointer receiver，在package名字和方法名之間多出了"*trace"字樣。另外，參數(shù)列表的第1個參數(shù)標(biāo)明了結(jié)構(gòu)體(t)地址。我們從堆棧信息中看到了內(nèi)部實現(xiàn)細(xì)節(jié)。
Packing
如果有多個參數(shù)可以填充到一個single word, 則這些參數(shù)值會合并打包：
Listing 10
01 package main
02
03 func main() {
04 ? ? Example(true, false, true, 25)
05 }
06?
07 func Example(b1, b2, b3 bool, i uint8) {
08 ? ? panic("Want stack trace")
09 }
這個例子修改Example函數(shù)為4個參數(shù)：3個bool型和1個八位無符號整型。bool值也是用8個bit表示，所以在32位和64位架構(gòu)下，4個參數(shù)可以合并為一個single word。
Listing 11
01 goroutine 1 [running]:
02 main.Example(0x19010001)
/Users/bill/Spaces/Go/Projects/src/github.com/goinaction/code/
temp/main.go:8 +0x64
03 main.main()
/Users/bill/Spaces/Go/Projects/src/github.com/goinaction/code/
temp/main.go:4 +0x32
這是本例的堆棧信息，看下圖的具體分析：
Listing 12
// Parameter values
true, false, true, 25
// Word value
Bits ? ?Binary ? ? ?Hex ? Value
00-07 ? 0000 0001 ??01? ??true
08-15 ? 0000 0000 ??00? ? false
16-23 ? 0000 0001 ??01? ? true
24-31 ? 0001 1001 ??19? ? 25
// Declaration
main.Example(b1, b2, b3 bool, i uint8)
// Stack trace
main.Example(0x19010001)
以上展示了參數(shù)值是如何匹配到4個參數(shù)的。當(dāng)我們看到堆棧信息中包括十六進(jìn)制值，需要知道這些值是如何傳遞的。
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)存。編譯器的這個分析過程就叫做逃逸分析。
所以你在一個函數(shù)中通過 dict := make(map[string]int) 創(chuàng)建一個 map 變量，其背后的數(shù)據(jù)是放在棧空間上還是堆空間上，是不一定的。這要看編譯器分析的結(jié)果。
可逃逸分析并不是百分百準(zhǔn)確的，它有缺陷。有的時候你會發(fā)現(xiàn)有些變量其實在?？臻g上分配完全沒問題的，但編譯后程序還是把這些數(shù)據(jù)放在了堆上。如果你了解 Go 語言編譯器逃逸分析的機(jī)制，在寫代碼的時候就可以有意識地繞開這些缺陷，使你的程序更高效。
Go 語言雖然在內(nèi)存管理方面降低了編程門檻，即使你不了解堆棧也能正常開發(fā)，但如果你要在性能上較真的話，還是要掌握這些基礎(chǔ)知識。
這里不對堆內(nèi)存和棧內(nèi)存的區(qū)別做太多闡述。簡單來說就是， 棧分配廉價，堆分配昂貴。 ?？臻g會隨著一個函數(shù)的結(jié)束自動釋放，堆空間需要時間 GC 模塊不斷地跟蹤掃描回收。如果對這兩個概念有些迷糊，建議閱讀下面 2 個文章：
這里舉一個小例子，來對比下堆棧的差別：
stack 函數(shù)中的變量 i 在函數(shù)退出會自動釋放；而 heap 函數(shù)返回的是對變量 i 的引用，也就是說 heap() 退出后，表示變量 i 還要能被訪問，它會自動被分配到堆空間上。
他們編譯出來的代碼如下：
邏輯的復(fù)雜度不言而喻，從上面的匯編中可看到， heap() 函數(shù)調(diào)用了 runtime.newobject() 方法，它會調(diào)用 mallocgc 方法從 mcache 上申請內(nèi)存，申請的內(nèi)部邏輯前面文章已經(jīng)講述過。堆內(nèi)存分配不僅分配上邏輯比棧空間分配復(fù)雜，它最致命的是會帶來很大的管理成本，Go 語言要消耗很多的計算資源對其進(jìn)行標(biāo)記回收（也就是 GC 成本）。
Go 編輯器會自動幫我們找出需要進(jìn)行動態(tài)分配的變量，它是在編譯時追蹤一個變量的生命周期，如果能確認(rèn)一個數(shù)據(jù)只在函數(shù)空間內(nèi)訪問，不會被外部使用，則使用?？臻g，否則就要使用堆空間。
我們在 go build 編譯代碼時，可使用 -gcflags '-m' 參數(shù)來查看逃逸分析日志。
以上面的兩個函數(shù)為例，編譯的日志輸出是：
日志中的 i escapes to heap 表示該變量數(shù)據(jù)逃逸到了堆上。
需要使用堆空間，所以逃逸，這沒什么可爭議的。但編譯器有時會將 不需要 使用堆空間的變量，也逃逸掉。這里是容易出現(xiàn)性能問題的大坑。網(wǎng)上有很多相關(guān)文章，列舉了一些導(dǎo)致逃逸情況，其實總結(jié)起來就一句話：
多級間接賦值容易導(dǎo)致逃逸 。
這里的多級間接指的是，對某個引用類對象中的引用類成員進(jìn)行賦值。Go 語言中的引用類數(shù)據(jù)類型有 func , interface , slice , map , chan , *Type(指針) 。
記住公式 Data.Field = Value ，如果 Data , Field 都是引用類的數(shù)據(jù)類型，則會導(dǎo)致 Value 逃逸。這里的等號 = 不單單只賦值，也表示參數(shù)傳遞。
根據(jù)公式，我們假設(shè)一個變量 data 是以下幾種類型，相應(yīng)的可以得出結(jié)論：
下面給出一些實際的例子：
如果變量值是一個函數(shù)，函數(shù)的參數(shù)又是引用類型，則傳遞給它的參數(shù)都會逃逸。
上例中 te 的類型是 func(*int) ，屬于引用類型，參數(shù) *int 也是引用類型，則調(diào)用 te(j) 形成了為 te 的參數(shù)(成員) *int 賦值的現(xiàn)象，即 te.i = j 會導(dǎo)致逃逸。代碼中其他幾種調(diào)用都沒有形成 多級間接賦值 情況。
同理，如果函數(shù)的參數(shù)類型是 slice , map 或 interface{} 都會導(dǎo)致參數(shù)逃逸。
匿名函數(shù)的調(diào)用也是一樣的，它本質(zhì)上也是一個函數(shù)變量。有興趣的可以自己測試一下。
只要使用了 Interface 類型(不是 interafce{} )，那么賦值給它的變量一定會逃逸。因為 interfaceVariable.Method() 先是間接的定位到它的實際值，再調(diào)用實際值的同名方法，執(zhí)行時實際值作為參數(shù)傳遞給方法。相當(dāng)于 interfaceVariable.Method.this = realValue
向 channel 中發(fā)送數(shù)據(jù)，本質(zhì)上就是為 channel 內(nèi)部的成員賦值，就像給一個 slice 中的某一項賦值一樣。所以 chan *Type , chan map[Type]Type , chan []Type , chan interface{} 類型都會導(dǎo)致發(fā)送到 channel 中的數(shù)據(jù)逃逸。
這本來也是情理之中的，發(fā)送給 channel 的數(shù)據(jù)是要與其他函數(shù)分享的，為了保證發(fā)送過去的指針依然可用，只能使用堆分配。
可變參數(shù)如 func(arg ...string) 實際與 func(arg []string) 是一樣的，會增加一層訪問路徑。這也是 fmt.Sprintf 總是會使參數(shù)逃逸的原因。
例子非常多，這里不能一一列舉，我們只需要記住分析方法就好，即，2 級或更多級的訪問賦值會 容易 導(dǎo)致數(shù)據(jù)逃逸。這里加上 容易 二字是因為隨著語言的發(fā)展，相信這些問題會被慢慢解決，但現(xiàn)階段，這個可以作為我們分析逃逸現(xiàn)象的依據(jù)。
下面代碼中包含 2 種很常規(guī)的寫法，但他們卻有著很大的性能差距，建議自己想下為什么。
Benchmark 和 pprof 給出的結(jié)果:
熟悉堆棧概念可以讓我們更容易看透 Go 程序的性能問題，并進(jìn)行優(yōu)化。
多級間接賦值會導(dǎo)致 Go 編譯器出現(xiàn)不必要的逃逸，在一些情況下可能我們只需要修改一下數(shù)據(jù)結(jié)構(gòu)就會使性能有大幅提升。這也是很多人不推薦在 Go 中使用指針的原因，因為它會增加一級訪問路徑，而 map , slice , interface{} 等類型是不可避免要用到的，為了減少不必要的逃逸，只能拿指針開刀了。
大多數(shù)情況下，性能優(yōu)化都會為程序帶來一定的復(fù)雜度。建議實際項目中還是怎么方便怎么寫，功能完成后通過性能分析找到瓶頸所在，再對局部進(jìn)行優(yōu)化。
重慶分公司
重慶分公司
