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

一桶冷水 · · 10216 次点击 · · 开始浏览    
这是一个创建于 的文章,其中的信息可能已经有所发展或是发生改变。

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,但是始终close body依然是好的编码习惯。


有疑问加站长微信联系(非本文作者)

本文来自:简书

感谢作者:一桶冷水

查看原文:[golang]为什么Response.Body需要被关闭

入群交流(和以上内容无关):加入Go大咖交流群,或添加微信:liuxiaoyan-s 备注:入群;或加QQ群:692541889

10216 次点击  ∙  1 赞  
加入收藏 微博
被以下专栏收入,发现更多相似内容
暂无回复
添加一条新回复 (您需要 登录 后才能回复 没有账号 ?)
  • 请尽量让自己的回复能够对别人有帮助
  • 支持 Markdown 格式, **粗体**、~~删除线~~、`单行代码`
  • 支持 @ 本站用户;支持表情(输入 : 提示),见 Emoji cheat sheet
  • 图片支持拖拽、截图粘贴等方式上传