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

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

來看個簡單的例子

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

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

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

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

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

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

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

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

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

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

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

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

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

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

拓展閱讀

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

拓展閱讀 Language Mechanics On Stacks And Pointers

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 截止日期?不管是遇到250 ms還是遇到?2019-01-08 01:00:00格式的時間，必須立刻終止執(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 (一個用于制作命令行應(yīng)用的庫)Go 應(yīng)用，一旦啟動，開發(fā)者繼承了一串上下文，使用 context 的終止信號來終止所有的執(zhí)行。當我意識到請求一個 gRPC 終端的時候，context 只是直接被傳遞了下去。這不是我想看到的。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

轉(zhuǎn)自：

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