前言
本文主要介紹了關于golang中Response.Body需要被關閉的相關內容,文中通過示例代碼介紹的非常詳細,對各位學習或者使用golang具有一定參考學習價值,下面話不多說了,來一起看看詳細的介紹吧
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事務:
- 主goroutine將request同時發給readLoop和writeLoop。
- writeLoop發送request,然后將狀態(error)發送給主goroutine和readLoop。
- readLoop解析頭部response,然后將狀態(error)和response發送給主goroutine。
- 主goroutine返回用戶代碼,readLoop等待body讀取完成。
- 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:
- bufio.Reader,這層嘗試將多次小的讀操作替換為一次大的讀操作,減少系統調用的次數,提高性能;
- io.LimitedReader,tcp連接在讀取完body后不會關閉,繼續讀會導致阻塞,所以需要LimitedReader在body讀完后發出eof終止讀取;
- chunkedReader,解析chunked格式編碼(如果不是chunked略過);
- bodyEOFSignal,在讀到eof,或者是提前關閉body時會對readLoop發出回收連接的通知;
- gzipReader,解析gzip壓縮(如果不是gizp壓縮略過);
從上面可以看出如果body既沒有被完全讀取,也沒有被關閉,那么這次http事務就沒有完成,除非連接因超時終止了,否則相關資源無法被回收。
如果請求頭或響應頭指明Connection: close呢?還是無法回收,因為close表示在http事務完成后斷開連接,而事務尚未完成自然不會斷開,更不會回收。
從實現上看只要body被讀完,連接就能被回收,只有需要拋棄body時才需要close,似乎不關閉也可以。但那些正常情況能讀完的body,即第一種情況,在出現錯誤時就不會被讀完,即轉為第二種情況。而分情況處理則增加了維護者的心智負擔,所以始終close body是最佳選擇。
總結
以上就是這篇文章的全部內容了,希望本文的內容對大家的學習或者工作具有一定的參考學習價值,如果有疑問大家可以留言交流,謝謝大家對腳本之家的支持。
您可能感興趣的文章:- golang設置http response響應頭與填坑記錄
- 解決golang處理http response碰到的問題和需要注意的點
- 解決Golang中ResponseWriter的一個坑