golang中为什么Response.Body需要被关闭详解-创新互联

前言

本文主要介绍了关于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}

另外有需要云服务器可以了解下创新互联scvps.cn，海内外云服务器15元起步，三天无理由+7*72小时售后在线，公司持有idc许可证，提供“云服务器、裸金属服务器、高防服务器、香港服务器、美国服务器、虚拟主机、免备案服务器”等云主机租用服务以及企业上云的综合解决方案，具有“安全稳定、简单易用、服务可用性高、性价比高”等特点与优势，专为企业上云打造定制，能够满足用户丰富、多元化的应用场景需求。