[golang]爲何Response Body須要被關閉

Body io.ReadCloser

The http Client and Transport guarantee that Body is always non-nil, even on 
responses without a body or responses with a zero-length body. It is the caller's responsibility to close Body. The default HTTP client's Transport does not attempt to 
reuse HTTP/1.0 or HTTP/1.1 TCP connections ("keep-alive") unless the Body is read to 
completion and is closed.

http客戶端(Client)和傳輸(Transport)保證響應體老是非空的，即便響應沒有響應體或0長響應
體。關閉響應體是調用者的責任。默認http客戶端傳輸(Transport)不會嘗試複用keep-alive的
http/1.0、http/1.1鏈接，除非請求體已被徹底讀出並且被關閉了。
複製代碼

以上是http包文檔說明。可是爲何body須要被關閉呢，不關閉會如何？那就讀源碼唄。

要了解body，首先要了解http事務是如何處理的。http事務是交由底層的Transport處理的。

第一步是從鏈接池獲取一個鏈接，這個鏈接的功能由3個goroutine協同實現，一個主goroutine，一個readLoop，一個writeLoop，後兩個goroutine生命週期和鏈接一致。雖然說readLoop和writeLoop名字叫循環（也確實是for循環），但實際上一次循環就完整處理一個http事務，循環自己僅僅是爲了鏈接複用，因此爲了便於理解其邏輯能夠忽略它的循環結構。

接下來三個goroutine協同完成http事務：

1. 主goroutine將request同時發給readLoop和writeLoop。
2. writeLoop發送request，而後將狀態（error）發送給主goroutine和readLoop。
3. readLoop解析頭部response，而後將狀態（error）和response發送給主goroutine。
4. 主goroutine返回用戶代碼，readLoop等待body讀取完成。
5. readLoop回收鏈接。

瞭解http事務的處理流程，而後咱們回過頭來看看神祕的body究竟是什麼

//源碼版本1.8.3
// src/net/http/transfer.go:405 body解析方法
func readTransfer(msg interface{}, r *bufio.Reader) (err error)

// src/net/http/transfer.go:485 解析chunked
t.Body = &body{src: internal.NewChunkedReader(r), hdr: msg, r: r, closing: t.Close}

// src/net/http/transfer.go:490 產生eof
t.Body = &body{src: io.LimitReader(r, realLength), closing: t.Close}

// src/net/http/transport.go:1560 發送eof信號
body := &bodyEOFSignal{

// src/net/http/transport.go:1583 gzip解碼
resp.Body = &gzipReader{body: body}
複製代碼

body其實是一個嵌套了多層的net.TCPConn：

1. bufio.Reader，這層嘗試將屢次小的讀操做替換爲一次大的讀操做，減小系統調用的次數，提升性能；
2. io.LimitedReader，tcp鏈接在讀取完body後不會關閉，繼續讀會致使阻塞，因此須要LimitedReader在body讀完後發出eof終止讀取；
3. chunkedReader，解析chunked格式編碼（若是不是chunked略過）；
4. bodyEOFSignal，在讀到eof，或者是提早關閉body時會對readLoop發出回收鏈接的通知；
5. gzipReader，解析gzip壓縮（若是不是gizp壓縮略過）；

從上面能夠看出若是body既沒有被徹底讀取，也沒有被關閉，那麼此次http事務就沒有完成，除非鏈接因超時終止了，不然相關資源沒法被回收。

若是請求頭或響應頭指明Connection: close呢？仍是沒法回收，由於close表示在http事務完成後斷開鏈接，而事務還沒有完成天然不會斷開，更不會回收。

從實現上看只要body被讀完，鏈接就能被回收，只有須要拋棄body時才須要close，彷佛不關閉也能夠。但那些正常狀況能讀完的body，即第一種狀況，在出現錯誤時就不會被讀完，即轉爲第二種狀況。而分狀況處理則增長了維護者的心智負擔，因此始終close body是最佳選擇。