前言

本文主要介紹了關于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到底是什么

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是最佳選擇。

總結

以上就是這篇文章的全部內容了，希望本文的內容對大家的學習或者工作具有一定的參考學習價值，如果有疑問大家可以留言交流，謝謝大家對服務器之家的支持。

原文鏈接：https://www.jianshu.com/p/407fada3cc9d