golang中为什么Response.Body需要被关闭详解
前言
本文主要介绍了关于golang中Response.Body需要被关闭的相关内容,文中通过示例代码介绍的非常详细,对各位学习或者使用golang具有一定参考学习价值,下面话不多说了,来一起看看详细的介绍吧
Bodyio.ReadCloser
ThehttpClientandTransportguaranteethatBodyisalwaysnon-nil,evenon
responseswithoutabodyorresponseswithazero-lengthbody.Itisthecaller's
responsibilitytocloseBody.ThedefaultHTTPclient'sTransportdoesnotattemptto
reuseHTTP/1.0orHTTP/1.1TCPconnections("keep-alive")unlesstheBodyisreadto
completionandisclosed.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:405body解析方法 funcreadTransfer(msginterface{},r*bufio.Reader)(errerror) //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:1583gzip解码 resp.Body=&gzipReader{body: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,即第一种情况,在出现错误时就不会被读完,即转为第二种情况。而分情况处理则增加了维护者的心智负担,所以始终closebody是最佳选择。
总结
以上就是这篇文章的全部内容了,希望本文的内容对大家的学习或者工作具有一定的参考学习价值,如果有疑问大家可以留言交流,谢谢大家对毛票票的支持。