本文總結了10種 go 語言編成中可能導致性能下降的壞實踐。有代碼潔癖的同學來自我檢查吧！

這篇文章主要講述了我在 Go 項目中見到過的常見錯誤清單，順序無關。

未知的Enum值

來看個簡單的例子

typeStatusuint32

const(
StatusOpenStatus=iota
StatusClose
StatusUnknown
)

在上面的代碼中，使用iota創(chuàng)建了一個enum類型，分別代指下面的狀態(tài)信息：

StatusOpen=0
StatusClose=1
StatusUnknown=2

現(xiàn)在，我們假設Status是一個 JSON 請求中被Marshalled / Unmarshalled的一個屬性，我們可以設計出下面的數(shù)據(jù)結構：

typeRequeststruct{
IDint`json:"Id"`
Timestampint`json:"Timestamp"`
StatusStatus`json:"Status"`
}

然后，假設收到的Request 的接口返回值為:

{
"Id":1234,
"Timestamp":1563362390,
"Status":0
}

到目前為止，沒有什么特殊的表達，Status將會被反序列化為StatusOpen，是吧？

好的，我們來看一個未設置status返回值的請求（不管是出于什么原因吧)。

{
"Id":1234,
"Timestamp":1563362390
}

在這個例子中，Request結構體的Status字段將會被初始化為默認零值zeroed value, 對于 uint32 類型來說，值就是0。因此，StatusOpen就替換掉了原本值應該是StatusUnknown。

對于這類場景，把unknown value設置為枚舉類型0應該比較合適，如下：

typeStatusuint32

const(
StatusUnknownStatus=iota
StatusOpen
StatusClose
)

這樣，即時返回的 JSON 請求中沒有Status屬性，結構體Request的Status屬性也會按我們預期的，被初始化為StatusUnknown。

性能測試

正確地進行性能測試很困難，因為過程中有太多的因素會影響測試結果了。

其中一個最常見的錯誤就是被一些編譯器優(yōu)化參數(shù)糊弄，讓我們以teivah/bitvector庫中的一個真實案例來進行闡述:

funcclear(nuint64,i,juint8)uint64{
return(math.MaxUint64<1<1))&n
}

這個函數(shù)會清理給定長度n的二進制位，對這個函數(shù)進行性能測試的話，我們可能會寫出下面的代碼:

funcBenchmarkWrong(b*testing.B){
fori:=0;i1221892080809121,10,63)
}
}

在這個性能測試中，編譯器發(fā)現(xiàn)clear函數(shù)是并沒有調(diào)用其他函數(shù)，因此編譯器就會進行inline處理。除此之外，編譯器還發(fā)現(xiàn)這個函數(shù)中也沒有side-effects。因此，clear就會被刪除，不去計算它的耗時，因此這就會導致測試結果的不準確。

一個建議是設置全局變量，如下：

varresultuint64

funcBenchmarkCorrect(b*testing.B){
varruint64
fori:=0;i1221892080809121,10,63)
}
result=r
}

這樣的話，編譯器就不知道clear函數(shù)是否會造成side-effect了，因此，性能測試的結果就會變得更加準確。

拓展閱讀

指針，到處都是指針！

值傳遞的時候，會創(chuàng)建一個同值變量；而指針傳遞的時候，只是將變量地址進行拷貝。

因此，指針傳遞總是會很快，是不？

如果你覺得是這樣，可以看一下這個例子。在這個性能測試中，一個大小為0.3K的數(shù)據(jù)結構分別以值傳遞和指針傳遞進行測試。0.3K 不大，但是也不能和大部分我們?nèi)粘Ｓ玫降膱鼍爸械臄?shù)據(jù)結構大小相差甚遠，接近即可。

當我在自己的本地環(huán)境中執(zhí)行這個性能測試代碼的時候，值傳遞比指針傳遞快了4 倍還多，是不是感覺有悖常理？

關于這個現(xiàn)象的解釋涉及到了 Go 中的內(nèi)存管理，我沒法解釋得像 William Kennedy 解釋的那樣精煉，一起來整理總結下吧：

變量可以被分配到heap和stack上，粗略解釋為：

• 棧包含哪些分配給了goroutine的隨時消失的變量，一旦函數(shù)返回，變量就會從棧中彈出
• 堆包含共享變量，比如全局變量等

一起通過一個簡單的例子來測試下：

funcgetFooValue()foo{
varresultfoo
//Dosomething
returnresult
}

result被當前 goroutine 創(chuàng)建，這個變量就會被壓入當前運行棧。一旦函數(shù)返回，調(diào)用方就會收到與此變量的一份拷貝，二者值相同，但是變量地址不同。變量本身會被彈出，此時變量并不會被立即銷毀，直到它的內(nèi)存地址被另一個變量覆蓋或者被擦除，這個時候它才是真的再也不會被訪問到了。

與此相對，看一個一個指針傳遞的例子：

funcgetFooPointer()*foo{
varresultfoo
//Dosomething
return&result
}

result依舊是被當前goroutine所創(chuàng)建，但是調(diào)用方收到的會是一個指針（指向變量的內(nèi)存地址）。如果result被棧彈出，那么調(diào)用方不可能訪問到此變量。

在這個場景下，GO 的編譯器會把result放置到可以被共享的變量空間：heap。

下面來看另一個場景，比如：

funcmain(){
p:=&foo{}
f(p)
}

f的調(diào)用方與f所屬為同一個goroutine，變量p不會被轉換，它只是被簡單放回到棧中，因此子函數(shù)依舊可以訪問到。

舉例來說，io.Reader中的Read方法接收指針，而不是返回一個，因為返回一個切片就會被轉換到堆中。

為什么棧會這么快？這里有兩個主要的原因：

• 棧不需要垃圾收集。正如我們所說，一個變量創(chuàng)建時被壓入棧，函數(shù)返回時從棧中彈出。根本不需要復雜的處理來回收未使用的變量。
• 一個棧隸屬于一個 goroutine，與堆中變量相比，不需要同步處理，這同樣會使得棧很快。

總結一下，當我們創(chuàng)建一個函數(shù)的時候，我們應該使用值傳遞而不是指針傳遞。只有我們期待某個變量被共享使用時，才使用指針傳遞適用。

當我們下次遇到性能優(yōu)化的問題時，一個可能的優(yōu)化方向就是檢查在某些場景下，指針傳遞是否真的會有所幫助。一個需要了解的常識是：當使用go build -gcflags "-m -m"時，編譯器會默認將一個變量轉換到堆中。

再強調(diào)下，在日常開發(fā)中，應該總是首先考慮值傳遞。

拓展閱讀 Language Mechanics On Stacks And Pointers

干掉for/switch或者for/select

如果f函數(shù)返回了 true，會發(fā)生什么？

for{
switchf(){
casetrue:
break
casefalse:
//dosomething
}
}

break語句會被調(diào)用，這會導致switch語句退出，而不是 loop 退出。再看一個類似問題：

for{
select{
case<-ch:
????????//dosomething
case<-ctx.Done():
????????break
}
}

break同樣只是退出select語句，而不是 for 循環(huán)。

一個可能的解決方案是使用labeled break標簽，例如：

loop:
for{
select{
case<-ch:
????????????//dosomething
case<-ctx.Done():
????????????breakloop
}
}

錯誤管理

Go 中的錯誤處理機制還是有點簡單，或許到了 Go2.0，它會變得好一點。

當前標準庫只提供創(chuàng)建錯誤類型數(shù)據(jù)結構的方法，具體可查看 pkg/errors。

這個庫很好的展示了一些本該被遵守卻經(jīng)常不被遵守的規(guī)則的好例子。

一個錯誤只應該被處理一次。把錯誤打印到日志中也是在處理錯誤。所以一個錯誤要么被打日志，要么被傳到調(diào)用方。

當前的標準庫，如果我們想分層化或者在錯誤中添加上下文信息是非常困難的。接下來，我們一起看個期待使用 REST 形式調(diào)用而導致 DB 出問題的例子：

unabletoserveHTTPPOSTrequestforcustomer1234
|_unabletoinsertcustomercontractabcd
|_unabletocommittransaction

如果我們使用pkg/errors庫，我們可能會這么做：

funcpostHandler(customerCustomer)Status{
err:=insert(customer.Contract)
iferr!=nil{
log.WithError(err).Errorf("unabletoserveHTTPPOSTrequestforcustomer%s",customer.ID)
returnStatus{ok:false}
}
returnStatus{ok:true}
}

funcinsert(contractContract)error{
err:=dbQuery(contract)
iferr!=nil{
returnerrors.Wrapf(err,"unabletoinsertcustomercontract%s",contract.ID)
}
returnnil
}

funcdbQuery(contractContract)error{
//Dosomethingthenfail
returnerrors.New("unabletocommittransaction")
}

需要我們使用errors.New來初始化錯誤信息（如果內(nèi)部方法調(diào)用沒有返回 error 的話）。中間調(diào)用層insert, 僅僅是通過添加更多上下文信息來包裝了錯誤。然后insert的調(diào)用方通過日志進行了打印，每一層要么返回錯誤，要么處理錯誤。

有些時候，我們可能會檢查錯誤以便于做重試處理。假如我們有一個叫db的處理數(shù)據(jù)庫的外部的包，這個庫可能會返回db.DBError 這種臨時錯誤。到底要不要做重試處理，就看錯誤是不是符合預期， 比如處理代碼：

funcpostHandler(customerCustomer)Status{
err:=insert(customer.Contract)
iferr!=nil{
switcherrors.Cause(err).(type){
default:
log.WithError(err).Errorf("unabletoserveHTTPPOSTrequestforcustomer%s",customer.ID)
returnStatus{ok:false}
case*db.DBError:
returnretry(customer)
}

}
returnStatus{ok:true}
}

funcinsert(contractContract)error{
err:=db.dbQuery(contract)
iferr!=nil{
returnerrors.Wrapf(err,"unabletoinsertcustomercontract%s",contract.ID)
}
returnnil
}

借助pkg/errors中的errors.Cause，便可以進行實現(xiàn)。

一個常見的錯誤就是獨立使用pkg/errors，比如：

switcherr.(type){
default:
log.WithError(err).Errorf("unabletoserveHTTPPOSTrequestforcustomer%s",customer.ID)
returnStatus{ok:false}
case*db.DBError:
returnretry(customer)
}

上面例子中，如果db.DBError被包裝了，那么重試機制將永遠不會觸發(fā)。

切片初始化

有時候我們知道切片的最終長度，比如：將切片Foo轉換成切片Bar，這意味著兩個切片的長度會是一致的。

我經(jīng)常見到有人這么初始化切片：

varbar[]Bar

bars:=make([]Bar,0)

切片不是魔術結構，實際上當空間不足時，Go來動態(tài)的維護切片的長度。在這個場景下，一個新的更大容量的數(shù)組會自動被創(chuàng)建，然后將舊的數(shù)組元素一個個的拷貝到新數(shù)組中。

現(xiàn)在，假設我們要多次數(shù)以千計的增加[]Foo，插入的時間復雜度可不是O(1)，畢竟內(nèi)部重復了多次拷貝。

因此，如果我們知道切片最終長度的話，可以采用以下策略：

• 使用預定義長度

funcconvert(foos[]Foo)[]Bar{
bars:=make([]Bar,len(foos))
fori,foo:=rangefoos{
bars[i]=fooToBar(foo)
}
returnbars
}

• 使用 0 長度，并且給一個預定義容量

funcconvert(foos[]Foo)[]Bar{
bars:=make([]Bar,0,len(foos))
for_,foo:=rangefoos{
bars=append(bars,fooToBar(foo))
}
returnbars
}

那么，這倆方法哪個更好呢？

第一個更快一點點，而第二個更符合編碼預期：不考慮初始長度，每次只通過append往尾部追加數(shù)據(jù)。

上下文管理

context.Context經(jīng)常被開發(fā)者所誤解，下面看下官方的解釋：

上下文以 API 邊界形式，可攜帶截止時間、取消信號以及其他值。

這段描述通常讓人疑惑這玩意兒有啥用，咋用啊？

我們舉幾個例子，看看它到底能攜帶什么數(shù)據(jù)：

• 截止日期不管是遇到250 ms還是遇到2019-01-08 0100格式的時間，必須立刻終止執(zhí)行（執(zhí)行的內(nèi)容可能是 I/O 請求，等待 channel 輸入等）
• 取消信號類似于上面，一旦接收到信號，就需要立刻終止執(zhí)行后續(xù)處理。例如：接收兩個請求，一個是插入數(shù)據(jù)，另一個是取消第一個的插入，這個場景就可以借助在第一個請求中加入一個可取消的上下文來實現(xiàn)。
• 其他值以Key-Value形式，即便都是 interface{}類型。

context 是可組合的，因此可以添加截止時間和其他 key-value 類型數(shù)據(jù)；另外，多個協(xié)程可共享同一個上下文，因此取消信號可以阻止多個執(zhí)行流程。

回到正題，繼續(xù)來說說錯誤問題。

一個 基于 urface/cli (一個用于制作命令行應用的庫)Go 應用，一旦啟動，開發(fā)者繼承了一串上下文，使用 context 的終止信號來終止所有的執(zhí)行。當我意識到請求一個 gRPC 終端的時候，context 只是直接被傳遞了下去。這不是我想看到的。

相反，我們想讓 gRPC 庫在收到終止信號或者超過 100ms 處理時間時進行取消處理。為了達到這個目標，我們可以創(chuàng)建一個簡單的組合上下文，如果parent是應用上下文的名字(通過 urfave/cli 創(chuàng)建)，然后我們就可以寫出下面的代碼：

ctx,cancel:=context.WithTimeout(parent,100*time.Millisecond)
response,err:=grpcClient.Send(ctx,request)

上下文不難理解，而且在我眼中，它是Go 語言中最棒的特色之一。

不要使用-race選項

我經(jīng)常見的一個錯誤就是在測試時使用-race選項。

“即使 Go 是被設計成讓并發(fā)更容易，更少錯誤的語言”， 我們?nèi)匀唤?jīng)受著很多并發(fā)問題的折磨。

顯而易見的是，Go 語言中的 race 探查器對獨立的并發(fā)問題而言并無幫助。不過，當測試我們的應用時開啟它也是很有價值的。

使用文件名作為輸入

另一個常見問題就是把文件名作為函數(shù)的參數(shù)。加入我們要實現(xiàn)一個統(tǒng)計文件中空行數(shù)量的函數(shù)，最自然的實現(xiàn)方式可能就是這樣的：

funccount(filenamestring)(int,error){
file,err:=os.Open(filename)
iferr!=nil{
return0,errors.Wrapf(err,"unabletoopen%s",filename)
}
deferfile.Close()

scanner:=bufio.NewScanner(file)
count:=0
forscanner.Scan(){
ifscanner.Text()==""{
count++
}
}
returncount,nil
}

filename作為函數(shù)輸入，然后我們打開文件，再實現(xiàn)后續(xù)的邏輯，對不？

接下來，在此函數(shù)的基礎上寫單測，測試使用的變量分別代表：常規(guī)文件，空文件，使用不同編碼的文件等等。很快它就會變得難以管理。

同樣，當我們想以同樣的邏輯來處理 HTTP 響應體，我們就不得不重新寫一個新函數(shù)了，因為這個函數(shù)只接受文件名。

GO 語言中有兩個很棒的抽象：io.Reader和io.Writer。與直接傳遞文件名不同的是，我們可以簡單的傳入一個io.Reader來抽象化數(shù)據(jù)源。

它是文件還是 HTTP 的響應體，或者是一個字節(jié)緩沖區(qū)？都不重要了，我們只需要使用Read方法就都可以搞定。在下面的例子中，我們甚至可以一行一行地讀入數(shù)據(jù)。

funccount(reader*bufio.Reader)(int,error){
count:=0
for{
line,_,err:=reader.ReadLine()
iferr!=nil{
switcherr{
default:
return0,errors.Wrapf(err,"unabletoread")
caseio.EOF:
returncount,nil
}
}
iflen(line)==0{
count++
}
}
}

打開一個文件的職責交給count的調(diào)用方去代理就好了，如下：

file,err:=os.Open(filename)
iferr!=nil{
returnerrors.Wrapf(err,"unabletoopen%s",filename)
}
deferfile.Close()
count,err:=count(bufio.NewReader(file))

在第二種的實現(xiàn)中，數(shù)據(jù)源已經(jīng)不重要了，并且單測也可以很方便的進行編寫,比如使用字符串來創(chuàng)建一個bufio.Reader作為數(shù)據(jù)源：

count,err:=count(bufio.NewReader(strings.NewReader("input")))

協(xié)程與循環(huán)變量

最后一個常見的錯誤就是在循環(huán)結構中使用協(xié)程。

下面例子中的輸出是什么？

ints:=[]int{1,2,3}
for_,i:=rangeints{
gofunc(){
fmt.Println("%v
",i)
}()
}

你是不是以為會是按順序輸出1 2 3？并不是哦。在這個例子中，每一個協(xié)程都會共享同一個變量實例，因此它最終大概率會輸出3 3 3。

有兩種解決方案來解決類似問題，第一個就是把循環(huán)遍歷當做參數(shù)傳給閉包，比如：

ints:=[]int{1,2,3}
for_,i:=rangeints{
gofunc(iint){
fmt.Printf("%v
",i)
}(i)
}

另一種方式就是在循環(huán)內(nèi)部的作用域中創(chuàng)建臨時變量，比如：

ints:=[]int{1,2,3}
for_,i:=rangeints{
i:=i
gofunc(){
fmt.Printf("%v
",i)
}()
}

雖然看著i := i很奇怪，但是它真的有效。一個循環(huán)內(nèi)部意味著在另一個作用域中，因此i := i就創(chuàng)建了一個新的變量實例，稱之為i。當然，為了可讀性我們也可以定義成一個別的名字。

轉自：

guoruibiao.blog.csdn.net/article/details/108054295