Go 項目中常見的 10 種錯誤

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

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

未知的`Enum`值

來看個簡單的例子

type Status uint32

const (
    StatusOpen Status = iota
    StatusClose
    StatusUnknown
)

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

StatusOpen    = 0
StatusClose   = 1
StatusUnknown = 2

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

type Request struct {
    ID         int     `json:"Id"`
    Timestamp  int     `json:"Timestamp"`
    Status     Status  `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 應該比較合適，如下：

type Status uint32

const (
    StatusUnknown Status  = iota
    StatusOpen
    StatusClose
)

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

性能測試

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

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

func clear(n uint64, i, j uint8) uint64 {
    return (math.MaxUint64<<j | ((1 << i) - 1)) & n
}

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

func BenchmarkWrong(b *testing.B) {
 for i := 0; i < b.N; i++ {
  clear(1221892080809121, 10, 63)
 }
}

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

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

var result uint64

func BenchmarkCorrect(b *testing.B) {
 var r uint64
 for i := 0; i < b.N; i++ {
  r = clear(1221892080809121, 10, 63)
 }
 result = r
}

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

拓展閱讀

指針，到處都是指針！

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

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

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

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

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

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

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

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

func getFooValue() foo {
    var result foo
    // Do something
    return result
}

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

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

func getFooPointer() *foo {
    var result foo
    // Do something
    return &result
}

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

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

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

func main() {
    p := &foo{}
    f(p)
}

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

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

爲什麼棧會這麼快？這裏有兩個主要的原因：

幹掉 `for/switch` 或者 `for/select`

for {
    switch f() {
    case true:
        break
    case false:
        // do something
    }
}

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

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

loop:
    for {
        select {
        case <-ch:
            // do something
        case <-ctx.Done():
            break loop
        }
    }

錯誤管理

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

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

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

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

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

unable to serve HTTP POST request for customer 1234
 |_ unable to insert customer contract abcd
     |_ unable to commit transaction

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

func postHandler(customer Customer) Status {
 err := insert(customer.Contract)
 if err != nil {
  log.WithError(err).Errorf("unable to serve HTTP POST request for customer %s", customer.ID)
  return Status{ok: false}
 }
 return Status{ok: true}
}

func insert(contract Contract) error {
 err := dbQuery(contract)
 if err != nil {
  return errors.Wrapf(err, "unable to insert customer contract %s", contract.ID)
 }
 return nil
}

func dbQuery(contract Contract) error {
 // Do something then fail
 return errors.New("unable to commit transaction")
}

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

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

func postHandler(customer Customer) Status {
 err := insert(customer.Contract)
 if err != nil {
  switch errors.Cause(err).(type) {
  default:
   log.WithError(err).Errorf("unable to serve HTTP POST request for customer %s", customer.ID)
   return Status{ok: false}
  case *db.DBError:
   return retry(customer)
  }

 }
 return Status{ok: true}
}

func insert(contract Contract) error {
 err := db.dbQuery(contract)
 if err != nil {
  return errors.Wrapf(err, "unable to insert customer contract %s", contract.ID)
 }
 return nil
}

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

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

switch err.(type) {
default:
  log.WithError(err).Errorf("unable to serve HTTP POST request for customer %s", customer.ID)
  return Status{ok: false}
case *db.DBError:
  return retry(customer)
}

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

切片初始化

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

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

var bar []Bar

bars := make([]Bar, 0)

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

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

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

使用預定義長度

func convert(foos []Foo) []Bar {
 bars := make([]Bar, len(foos))
 for i, foo := range foos {
  bars[i] = fooToBar(foo)
 }
 return bars
}

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

func convert(foos []Foo) []Bar {
 bars := make([]Bar, 0, len(foos))
 for _, foo := range foos {
  bars = append(bars, fooToBar(foo))
 }
 return bars
}

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

第一個更快一點點，而第二個更符合編碼預期：不考慮初始長度，每次只通過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 創建)，然後我們就可以寫出下面的代碼：

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

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

不要使用`-race`選項

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

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

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

使用文件名作爲輸入

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

func count(filename string) (int, error) {
 file, err := os.Open(filename)
 if err != nil {
  return 0, errors.Wrapf(err, "unable to open %s", filename)
 }
 defer file.Close()

 scanner := bufio.NewScanner(file)
 count := 0
 for scanner.Scan() {
  if scanner.Text() == "" {
   count++
  }
 }
 return count, nil
}

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

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

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

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

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

func count(reader *bufio.Reader) (int, error) {
 count := 0
 for {
  line, _, err := reader.ReadLine()
  if err != nil {
   switch err {
   default:
    return 0, errors.Wrapf(err, "unable to read")
   case io.EOF:
    return count, nil
   }
  }
  if len(line) == 0 {
   count++
  }
 }
}

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

file, err := os.Open(filename)
if err != nil {
  return errors.Wrapf(err, "unable to open %s", filename)
}
defer file.Close()
count, err := count(bufio.NewReader(file))

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

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

協程與循環變量

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

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

ints := []int{1, 2, 3}
for _, i := range ints {
    go func(){
        fmt.Println("%v\n", i)
    }()
}

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

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

ints := []int{1, 2, 3}
for _, i := range ints {
  go func(i int) {
    fmt.Printf("%v\n", i)
  }(i)
}

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

ints := []int{1, 2, 3}
for _, i := range ints {
  i := i
  go func() {
    fmt.Printf("%v\n", i)
  }()
}

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

轉自：

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

Go 開發大全

參與維護一個非常全面的 Go 開源技術資源庫。日常分享 Go, 雲原生、k8s、Docker 和微服務方面的技術文章和行業動態。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/8bxp1_M8EL89haadOX0Nuw

未知的Enum值