前言
本文主要介绍了关于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事务：
了解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：
从上面可以看出如果body既没有被完全读取，也没有被关闭，那么这次http事务就没有完成，除非连接因超时终止了，否则相关资源无法被回收。
如果请求头或响应头指明connection: close呢？还是无法回收，因为close表示在http事务完成后断开连接，而事务尚未完成自然不会断开，更不会回收。
从实现上看只要body被读完，连接就能被回收，只有需要抛弃body时才需要close，似乎不关闭也可以。但那些正常情况能读完的body，即第一种情况，在出现错误时就不会被读完，即转为第二种情况。而分情况处理则增加了维护者的心智负担，所以始终close body是最佳选择。
总结
以上就是这篇文章的全部内容了，希望本文的内容对大家的学习或者工作具有一定的参考学习价值，如果有疑问大家可以留言交流，谢谢大家对移动技术网的支持。
如对本文有疑问， 点击进行留言回复！！
网友评论