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

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

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

?

輸出結果：

?

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

構造并發操作map的場景：

?

輸出結果：

?

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

a) 通過編寫代碼校驗，防止能預期到的panic，比如：空指針引用的指針判斷。

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

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

相關參考：

關于并發讀寫map導致的panic無法使用recover()捕獲，是Go1.6增加的一個特性，https://golang.org/doc/go1.6#runtime；

當然這個并非是唯一一個無法通過recover()捕獲的場景，還有可能Go本身的bug，https://github.com/golang/go/issues/21717；這個Bug在Go1.9.2才修復

2、 【嚴重】小心Map的內存泄露

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

?

增加環境變量GODEBUG=gctrace=1，運行可見，即使代碼邏輯清空了map，但進程內存使用并沒有像預期那樣“實報實銷”：

?

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

?

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

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

?

輸出結果：

?

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

?

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

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

?

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

?

我們把代碼調整如下：

?

再看看連接數統計：

?

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

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

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

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

?

轉載于:https://www.cnblogs.com/hwpaas/p/9233583.html

總結

以上是生活随笔為你收集整理的使用Golang时遇到的一些坑的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。