go新手容易犯的三個致命錯誤

TIGERB發表於2019-02-16
Go

前言

最近因為以前一些重要且古老的go專案基本沒有人專職維護了，所以被安排去熟悉這些專案的程式碼，所以看了大量go的程式碼。歷史原因，這些程式碼中或多或少有一些剛剛從PHPer轉過來的Gopher去設計和開發的，自然有不少是在php(fpm模式下)碼程式碼思路下埋藏的一些坑。今天我就來和大家一起分享一下最近發現的比較不容易發現和出現比率比較高的三個致命錯誤。

三個致命錯誤

致命錯誤一: defer的錯誤使用

  • 現象：死迴圈程式碼塊中直接使用defer(非函式內部的defer)
  • 問題：defer程式碼一直不會執行
  • 例如：下面的示例，正常情況下defer redisConn.Close()一直不會執行，所以redis的連線數會持續增長得不到釋放，搞不好redis直接被打掛。
  • 經驗：監測服務資源發現socket(redis/mysql等)連線持續增長，就需要我們去找程式碼裡出現的類似的程式碼了

監測redis連線數會持續增長命令： `watch -n 2 “redis-cli -h 127.0.0.1 -p 6379 info | grep `connected_clients`” 下面的程式碼會導致connected_clients持續增長
`

package main

import (
    "fmt"
    "time"

    "github.com/gomodule/redigo/redis"
)

var RedisPool *redis.Pool

func init() {
    RedisPool = NewRedisPool()
    fmt.Println("RedisPool.Stats: ", RedisPool.Stats())
}

func main() {
    for {
        redisConn := RedisPool.Get()
        // 下意識的defer 但是忘了是在for迴圈了 除了程式掛了基本是不會執行這個defer了 資源得不到釋放
        defer redisConn.Close()

        // 一堆業務邏輯
        _, err := redisConn.Do("set", "demo_key", "666")
        if err != nil {
            fmt.Println("redis set err: ", err.Error())
            continue
        }
        res, _ := redis.String(redisConn.Do("get", "demo_key"))
        fmt.Println("get demo_key: ", res)
        time.Sleep(1 * time.Second)
    }
}

func NewRedisPool() *redis.Pool {
    return &redis.Pool{
        MaxIdle:     6,
        IdleTimeout: 240 * time.Second,
        Dial: func() (redis.Conn, error) {
            c, err := redis.Dial("tcp", "127.0.0.1:6379")
            if err != nil {
                return nil, err
            }
            return c, nil
        },
        TestOnBorrow: func(c redis.Conn, t time.Time) error {
            if time.Since(t) < time.Minute {
                return nil
            }
            _, err := c.Do("PING")
            return err
        },
    }
}

致命錯誤二: 死迴圈中一直持有一個連線

  • 現象：死迴圈外面獲取的連線，在死迴圈中使用，所以直到程式掛掉為止，這個goroutine一直持有該連線
  • 問題：如果資源服務端因為種種原因主動掛掉了這個連線(比如服務端超時)，這個迴圈的程式碼之後就永遠連線服務，程式碼邏輯就不用說了基本無法正常執行
  • 例如：下面的示例，redis因為redis proxy超時主動關閉了連線，就會報EOF
  • 經驗：如果服務大範圍報EOF錯誤，就需要我們去排查類似的程式碼了
package main

import (
    "fmt"
    "time"

    "github.com/gomodule/redigo/redis"
)

var RedisPool *redis.Pool

func init() {
    RedisPool = NewRedisPool()
    fmt.Println("RedisPool.Stats: ", RedisPool.Stats())
}

func main() {
    // 死迴圈外面獲取的連線 所以直到程式掛掉這個goroutine一直持有是這個連線
    redisConn := RedisPool.Get()
    defer redisConn.Close()
    
    for {
        // 一堆業務邏輯
        _, err := redisConn.Do("set", "demo_key", "666")
        if err != nil {
            fmt.Println("redis set err: ", err.Error())
            continue
        }
        res, _ := redis.String(redisConn.Do("get", "demo_key"))
        fmt.Println("get demo_key: ", res)
        time.Sleep(1 * time.Second)
    }
}

func NewRedisPool() *redis.Pool {
    return &redis.Pool{
        MaxIdle:     6,
        IdleTimeout: 240 * time.Second,
        Dial: func() (redis.Conn, error) {
            c, err := redis.Dial("tcp", "127.0.0.1:6379")
            if err != nil {
                return nil, err
            }
            return c, nil
        },
        TestOnBorrow: func(c redis.Conn, t time.Time) error {
            if time.Since(t) < time.Minute {
                return nil
            }
            _, err := c.Do("PING")
            return err
        },
    }
}

致命錯誤三：err.Error()使用位置不對

  • 現象：有時候打業務log的時候，獲取錯誤資訊err.Error()的程式碼忘了寫在err !=nil裡
  • 問題：程式碼可以編譯通過，但是執行到該處程式碼塊時空指標panic
  • 問題：例下面的示例，模擬業務中某些情況才會執行下面的程式碼塊
  • 經驗：養成強型別語言下嚴謹的邏輯習慣
package main

import (
    "fmt"
    "log"
    "time"
)

func main() {
    var i int
    ticker := time.NewTicker(1 * time.Second)
    for v := range ticker.C {
        fmt.Println(v, i)
        i = i + 1
        // 模擬業務中某些情況才會執行下面的程式碼塊
        if i == 6 {
            res, err := Simulate(i)
            // 有時候打業務log的時候 獲取錯誤資訊 err.Error() 的程式碼忘了寫在err != nil裡 導致空指標
            log.Println(fmt.Sprintf("res:%t i:%d err:%s", res, i, err.Error()))
            if err != nil {
                return
            }
        }
    }
}

func Simulate(i int) (b bool, err error) {
    return true, nil
}

程式碼可以編譯通過，但是執行到該處程式碼塊時空指標panic，如下模擬：

2019-01-19 23:56:48.044504 +0800 CST m=+1.005583125 0
2019-01-19 23:56:49.039491 +0800 CST m=+2.000557249 1
2019-01-19 23:56:50.03956 +0800 CST m=+3.000614086 2
2019-01-19 23:56:51.043367 +0800 CST m=+4.004408337 3
2019-01-19 23:56:52.040469 +0800 CST m=+5.001497207 4
2019-01-19 23:56:53.039643 +0800 CST m=+6.000658300 5
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x20 pc=0x1097a7f]

goroutine 1 [running]:
main.main()
        /Users/tigerb/github/easy-tips/go/src/go-learn/main.go:19 +0x1df

結語

最後說一句，像我們這樣從PHPer(fmp)轉過來的Gopher，碼程式碼的時候一定要考慮到我們是在常駐記憶體的場景下程式設計，例如並不限於下面三點：

  • 全域性變數
  • 執行緒安全
  • 資源回收

圖片描述

相關文章