转 [golang]为什么Response.Body需要被关闭

1. 
   Body io.ReadCloser
2.  
    
3.  
   The http Client and Transport guarantee that Body is always non-nil, even on
4.  
   responses without a body or responses with a zero-length body. It is the caller's
5.  
   responsibility to close Body. The default HTTP client's Transport does not attempt to
6.  
   reuse HTTP/1.0 or HTTP/1.1 TCP connections ("keep-alive") unless the Body is read to
7.  
   completion and is closed.
8.  
    
9.  
   http客户端(Client)和传输(Transport)保证响应体总是非空的，即使响应没有响应体或0长响应
10.  
    体。关闭响应体是调用者的责任。默认http客户端传输(Transport)不会尝试复用keep-alive的
11.  
    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.  
   //源码版本1.8.3
2.  
   // src/net/http/transfer.go:405 body解析方法
3.  
   func readTransfer(msg interface{}, r *bufio.Reader) (err error)
4.  
    
5.  
   // src/net/http/transfer.go:485 解析chunked
6.  
   t.Body = &body{src: internal.NewChunkedReader(r), hdr: msg, r: r, closing: t.Close}
7.  
    
8.  
   // src/net/http/transfer.go:490 产生eof
9.  
   t.Body = &body{src: io.LimitReader(r, realLength), closing: t.Close}
10.  
     
11.  
    // src/net/http/transport.go:1560 发送eof信号
12.  
    body := &bodyEOFSignal{
13.  
     
14.  
    // src/net/http/transport.go:1583 gzip解码
15.  
    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是最佳选择。

作者：一桶冷水
链接：https://www.jianshu.com/p/407fada3cc9d
來源：简书
简书著作权归作者所有，任何形式的转载都请联系作者获得授权并注明出处。