ᕕ( ᐛ )ᕗ Jimyag's Blog

为什么 Request.Body 需要被关闭

面试时被问到为什么 request 中的 body 被访问一次就不能再次访问了。

// Body is the request's body.
//
// For client requests, a nil body means the request has no body, such as a GET request. 
// 对于客户端请求,nil 正文表示请求没有 body 例如 GET 请求。
// The HTTP Client's Transport is responsible for calling the Close method.
// 对于 HTTP 客户端的传输负责调用 Close 方法。
// For server requests, the Request Body is always non-nil but will return EOF immediately when no body is present.
// 对于服务器请求,Request Body 始终为非 nil,但在没有 body 时将立即返回 EOF。
// The Server will close the request body. The ServeHTTP Handler does not need to.
// Server 将关闭请求正文。ServeHTTP 处理程序不需要这样做。
// Body must allow Read to be called concurrently with Close.
// body 必须允许与"关闭"同时调用"读取"。
// In particular, calling Close should unblock a Read waiting for input.
// 特别是,调用 Close 应取消阻止等待输入的读取。
Body io.ReadCloser

以上是 http 包文档说明。但是为什么 body 需要被关闭呢,不关闭会如何?

要了解 body,首先要了解 http 事务是如何处理的。http 事务是交由底层的 Transport 处理的。

  1. 从连接池获取一个连接,这个连接的功能由 3 个 goroutine 协同实现,一个主goroutine,一个readLoop(net/http/response.go:2052),一个writeLoop(net/http/response.go:2383),后两个 goroutine 生命周期和连接一致。

    虽说 readLoop 和 writeLoop 名字叫循环(也确实是 for 循环),但实际上是一次循环就完整处理一个 http 事务,循环本身仅仅是为了连接复用,所以为了便于理解其逻辑可以忽略它的循环结构。

  2. 接下来三个 goroutine 协同完成 http 事务:

    1. 主 goroutine 将 request 同时发给 readLoop 和 writeLoop。
    2. writeLoop 发送 request,然后将状态(error)发送给主 goroutine 和 readLoop。
    3. readLoop 解析头部,然后将状态(error)和 response 发送给主 goroutine。
    4. 主 goroutine 返回用户代码,readLoop 等待 body 读取完成。
    5. readLoop 回收连接。

了解 http 事务的处理流程,然后我们回过头来看看神秘的 body 到底是什么

//源码版本 1.17
// src/net/http/transfer.go:483 body 解析方法
func readTransfer(msg interface{}, r *bufio.Reader) (err error)
...
// src/net/http/transfer.go:560 解析 chunked
t.Body = &body{src: internal.NewChunkedReader(r), hdr: msg, r: r, closing: t.Close}

// src/net/http/transfer.go:565 产生 eof
t.Body = &body{src: io.LimitReader(r, realLength), closing: t.Close}

// src/net/http/transport.go:2167 发送 eof 信号
body := &bodyEOFSignal{

// src/net/http/transport.go:2191 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,似乎不关闭也可以。但那些正常情况能读完的 body,即第一种情况,在出现错误时就不会被读完,即转为第二种情况。而分情况处理则增加了维护者的心智负担,所以始终 close body 是最佳选择

简单的来说就是,原生的 http 包里,每发生一次 http 请求,在过程中会生成两个协程,一个负责写入 request (persistConn.writeLoop),一个负责读 response (persistConn.readLoop), 这两个方法,。由于两个协程是用 for+select 构成的,所以在没有接收到结束信号

之前,都会阻塞住,导致 goroutine 无法退出,当请求量过大时,gotoutine 不能及时释放,就会导致 gotoutine 数量突增。

只要这时候只要你读取完 body 的内容,他就会自动关闭。这样就可以防止内存泄漏。

参考

《GO goroutine 暴涨与 response.Body.Close() 的关联》 - 热爱可抵岁月漫长 (jiangailang.cn)

[golang]为什么 Response.Body 需要被关闭 - 简书 (jianshu.com)

Go http 请求(get/post)必须要手动 resp.Body.Close (zhangjiee.com)

#go #踩坑 #源码