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

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

來看個簡單的例子

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

現在，我們假設Status?是一個 JSON 請求中被Marshalled / Unmarshalled的一個屬性，我們可以設計出下面的數據結構：

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

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

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

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

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

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

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

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

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

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

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

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

拓展閱讀

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

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

如果你覺得是這樣，可以看一下這個例子。在這個性能測試中，一個大小為0.3K的數據結構分別以值傳遞和指針傳遞進行測試。0.3K 不大，但是也不能和大部分我們日常用到的場景中的數據結構大小相差甚遠，接近即可。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

再強調下，在日常開發中，應該總是首先考慮值傳遞。

拓展閱讀 Language Mechanics On Stacks And Pointers

如果f函數返回了 true，會發生什么？

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

break?同樣只是退出select語句，而不是 for 循環。

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

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

當前標準庫只提供創建錯誤類型數據結構的方法，具體可查看 pkg/errors。

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

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

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

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

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

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

借助?pkg/errors?中的?errors.Cause，便可以進行實現。

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

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

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

我經常見到有人這么初始化切片：

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

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

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

• 使用預定義長度

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

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

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

context.Context?經常被開發者所誤解，下面看下官方的解釋：

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

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

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

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

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

回到正題，繼續來說說錯誤問題。

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

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

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

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

“即使 Go 是被設計成讓并發更容易，更少錯誤的語言”， 我們仍然經受著很多并發問題的折磨。

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

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

filename作為函數輸入，然后我們打開文件，再實現后續的邏輯，對不？

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

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

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

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

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

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

最后一個常見的錯誤就是在循環結構中使用協程。

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

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

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

另一種方式就是在循環內部的作用域中創建臨時變量，比如：

轉自：

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