本文總結(jié)了10種 go 語言編成中可能導(dǎo)致性能下降的壞實(shí)踐。有代碼潔癖的同學(xué)來自我檢查吧！

這篇文章主要講述了我在 Go 項(xiàng)目中見到過的常見錯(cuò)誤清單，順序無關(guān)。

未知的Enum值

來看個(gè)簡單的例子

typeStatusuint32

const(
StatusOpenStatus=iota
StatusClose
StatusUnknown
)

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

StatusOpen=0
StatusClose=1
StatusUnknown=2

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

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

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

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

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

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

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

在這個(gè)例子中，Request結(jié)構(gòu)體的Status字段將會(huì)被初始化為默認(rèn)零值zeroed value, 對(duì)于 uint32 類型來說，值就是0。因此，StatusOpen就替換掉了原本值應(yīng)該是StatusUnknown。

對(duì)于這類場(chǎng)景，把unknown value設(shè)置為枚舉類型0應(yīng)該比較合適，如下：

typeStatusuint32

const(
StatusUnknownStatus=iota
StatusOpen
StatusClose
)

這樣，即時(shí)返回的 JSON 請(qǐng)求中沒有Status屬性，結(jié)構(gòu)體Request的Status屬性也會(huì)按我們預(yù)期的，被初始化為StatusUnknown。

性能測(cè)試

正確地進(jìn)行性能測(cè)試很困難，因?yàn)檫^程中有太多的因素會(huì)影響測(cè)試結(jié)果了。

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

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

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

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

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

一個(gè)建議是設(shè)置全局變量，如下：

varresultuint64

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

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

拓展閱讀

指針，到處都是指針！

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

因此，指針傳遞總是會(huì)很快，是不？

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

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

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

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

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

一起通過一個(gè)簡單的例子來測(cè)試下：

funcgetFooValue()foo{
varresultfoo
//Dosomething
returnresult
}

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

與此相對(duì)，看一個(gè)一個(gè)指針傳遞的例子：

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

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

在這個(gè)場(chǎng)景下，GO 的編譯器會(huì)把result放置到可以被共享的變量空間：heap。

下面來看另一個(gè)場(chǎng)景，比如：

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

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

舉例來說，io.Reader中的Read方法接收指針，而不是返回一個(gè)，因?yàn)榉祷匾粋€(gè)切片就會(huì)被轉(zhuǎn)換到堆中。

為什么棧會(huì)這么快？這里有兩個(gè)主要的原因：

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

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

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

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

拓展閱讀 Language Mechanics On Stacks And Pointers

干掉for/switch或者for/select

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

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

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

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

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

一個(gè)可能的解決方案是使用labeled break標(biāo)簽，例如：

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

錯(cuò)誤管理

Go 中的錯(cuò)誤處理機(jī)制還是有點(diǎn)簡單，或許到了 Go2.0，它會(huì)變得好一點(diǎn)。

當(dāng)前標(biāo)準(zhǔn)庫只提供創(chuàng)建錯(cuò)誤類型數(shù)據(jù)結(jié)構(gòu)的方法，具體可查看 pkg/errors。

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

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

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

unabletoserveHTTPPOSTrequestforcustomer1234
|_unabletoinsertcustomercontractabcd
|_unabletocommittransaction

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

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來初始化錯(cuò)誤信息（如果內(nèi)部方法調(diào)用沒有返回 error 的話）。中間調(diào)用層insert, 僅僅是通過添加更多上下文信息來包裝了錯(cuò)誤。然后insert的調(diào)用方通過日志進(jìn)行了打印，每一層要么返回錯(cuò)誤，要么處理錯(cuò)誤。

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

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，便可以進(jìn)行實(shí)現(xiàn)。

一個(gè)常見的錯(cuò)誤就是獨(dú)立使用pkg/errors，比如：

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

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

切片初始化

有時(shí)候我們知道切片的最終長度，比如：將切片Foo轉(zhuǎn)換成切片Bar，這意味著兩個(gè)切片的長度會(huì)是一致的。

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

varbar[]Bar

bars:=make([]Bar,0)

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

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

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

• 使用預(yù)定義長度

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

• 使用 0 長度，并且給一個(gè)預(yù)定義容量

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

那么，這倆方法哪個(gè)更好呢？

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

上下文管理

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

上下文以 API 邊界形式，可攜帶截止時(shí)間、取消信號(hào)以及其他值。

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

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

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

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

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

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

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

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

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

不要使用-race選項(xiàng)

我經(jīng)常見的一個(gè)錯(cuò)誤就是在測(cè)試時(shí)使用-race選項(xiàng)。

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

顯而易見的是，Go 語言中的 race 探查器對(duì)獨(dú)立的并發(fā)問題而言并無幫助。不過，當(dāng)測(cè)試我們的應(yīng)用時(shí)開啟它也是很有價(jià)值的。

使用文件名作為輸入

另一個(gè)常見問題就是把文件名作為函數(shù)的參數(shù)。加入我們要實(shí)現(xiàn)一個(gè)統(tǒng)計(jì)文件中空行數(shù)量的函數(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ù)輸入，然后我們打開文件，再實(shí)現(xiàn)后續(xù)的邏輯，對(duì)不？

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

同樣，當(dāng)我們想以同樣的邏輯來處理 HTTP 響應(yīng)體，我們就不得不重新寫一個(gè)新函數(shù)了，因?yàn)檫@個(gè)函數(shù)只接受文件名。

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

它是文件還是 HTTP 的響應(yīng)體，或者是一個(gè)字節(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++
}
}
}

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

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

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

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

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

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

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

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

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

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

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

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

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

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

轉(zhuǎn)自：

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