1、【致命】不是所有Panic都能捕獲

我們知道Golang給開發人員提供recover()機制，對堆疊異常（panic）進行捕獲並自定義其處理邏輯。下面舉個例子：

構造一個除0的異常場景：

程式碼：

package main

import “fmt”

func func1 () {

defer func () {

if e : = recover () ; e ! = nil {

fmt.Println(“Recover!”, e)

}

} ()

i : = 0

fmt.Println(“Panic:”, 1/i)

}

func main () {

func1 ()

}

輸出結果：

Recover! Runtime error:integer divide by zero

Process finished with exit code 0

我們看到程式正常退出，沒有異常，說明recover()按照預期捕獲到panic異常；但不是所有panic都能透過recover()捕捉到的，比如：併發操作map例項。

構造併發操作map的場景：

程式碼如下：

package main

import “fmt”

func func2() {

defer func () {

if e : = recover() ; e ! = nil {

fmt.Println(“Recover!”, e)

}

} ()

m : =make(map[i|nt]int)

go func () {

for {

m[0] = 0

}

} ()

for {

fmt.Println(“Panic:”,m[0])

}

func main() {

func2()

}

輸出結果：

Panic: 0

Fatal error: concurrent map read and map write

……

Process finished with exit code 2

以上結果可知，我們不能單純依靠recover()解決函式內部所有panic異常，應該做到以下幾點：

a) 透過編寫程式碼校驗，防止能預期到的panic，比如：空指標引用的指標判斷。

b) 對於無法預期的panic，使用recover()捕獲並加以處理。

c) 使用map時，必須要考慮是否存在併發讀寫場景，存在時，應使用ConcurrentMap元件或自己加sync.RWMutex進行加鎖保護。

相關參考：

關於併發讀寫map導致的panic無法使用recover()捕獲，是Go1.6增加的一個特性，；

當然這個並非是唯一一個無法透過recover()捕獲的場景，還有可能Go本身的bug，；這個Bug在Go1.9.2才修復

2、【嚴重】小心Map的記憶體洩露

大部分Golang程式做業務快取實現時，都使用了map，看以下程式碼片段，簡單模擬了這種使用場景：

程式碼如下：

Package main

import (

“strings”

“time”

“runtime/debug”

)

func main() {

m : = make(map[int]string)

s : = strings.Repeat(“x”, 1024)

for i : = 0; i < 10000000;i|++ {

m[i] = s

}

for i : = 0;i < 10000000;i++{

delete(m, i)

}

for {

debug.FreeOSMemory ()

time.Sleep(time.Second)

}

增加環境變數GODEBUG=gctrace=1，執行可見，即使程式碼邏輯清空了map，但程式記憶體使用並沒有像預期那樣“實報實銷”：

應如何解決：定期替換成新的map，釋放舊的map物件。

3、【提示】不是每次Map遍歷都能得到相同排序的集合

經常遇到一些業務場景，需要將map的所有元素列印輸出，在Golang裡面實現是非常簡單的，一個for range就可以實現，但結果卻有點出人意料：

呈上程式碼：

package main

import “fmt”

func main() {

m := make(map[int]int)

for i := 0; i < 100; i++ {

m[i] = i

}

for k := range m {

fmt.Print(k, “,”)

}

fmt.Println()

for k := range m {

fmt.Print(k, “,”)

}

fmt.Println()

}

輸出結果：

37,45,48,63,77,97,0,……

57,65,2,49,43,44,53,……

Process finished with exit code 0

兩次遍歷的結果均不相同，這是為什麼呢？這是Golang故意增加的一個隨機數導致的，https://blog.golang.org/go-maps-in-action；所以如果對結果一致性有要求的業務邏輯，就不能簡單的遍歷map了，可以這樣實現：

程式碼君：

import “sort”

var m map[int]string

var keys []int

for k := range m {

keys = append(keys, k)

}

sort.Ints(keys)

for _, k := range keys {

fmt.Println(“Key:”, k, “Value:”, m[k])

}

4、【嚴重】客戶端執行Response.Body.Close()後HTTP連線真的關閉了嗎？

按照官方文件對標準庫中的http client包的說明，在使用時需要主動呼叫Response.Body.Close()將連線關閉，但並不說明只要寫了這句話就能關閉連線的。看看以下場景：

package main

import (

“fmt”

“net/http”

“time”

)

func main() {

cli := &http.Client{}

for {

resp, err :=

cli.Get(“”)

if err != nil {

fmt.Println(err)

return

}

fmt.Println(“status:”, resp.StatusCode)

resp.Body.Close()

time.Sleep(500*time.Millisecond)

}

執行後，統計了下連線數，發現大量TIME_WAIT連線沒有按預期回收，看來Response.Body.Close()沒生效。

D:\>netstat /n|find /c “30100”

234

我們把程式碼調整如下：

fmt.Println(“status:”, resp.StatusCode)

io.Copy(ioutil.Discard, resp.Body) // add this

resp.Body.Close()

time.Sleep(500*time.Millisecond)

再看看連線數統計：

D:\>netstat /n|find /c “30100”

1

為什麼？以上是個較為特殊的場景，業務只關心請求的響應碼，並不關心響應體，所以沒有加入讀取resp.Body的程式碼。可以看到此時關閉Body讀取資料通道，會導致Golang底層沒有真正關閉連線。要解決這個這種場景出現的連線洩露問題，需要在Close前額外加入io.Copy(ioutil.Discard, resp.Body)，來完成TCP響應體讀取流程。

手打勿噴。Go語言未來的前景很不錯，而在國內的大廠中，華為雲對此的支援還是可以的，在其微服務應用平臺、微服務引擎中開放了Go語言的服務框架。

目前，華為雲有一個關於微服務的活動，有想應用服務微服務化需求的朋友可以考慮試用一下！

https://activity.huaweicloud.com/cse/index.html?dfk

使用Golang時遇到的一些坑

相關文章