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，碼代碼的時候必定要考慮到咱們是在常駐內存的場景下編程，例如並不限於下面三點：

• 全局變量
• 線程安全
• 資源回收