【踩坑記】使用Golang時遇到的一些坑

限時免費體驗華為云微服務

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響應體讀取流程。

立即體驗華為微服務CSE：https://console.huaweicloud.com/cse/?region=cn-north-1#/cse/home

了解詳情：https://www.huaweicloud.com/product/cse.html

Go

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。