释放有限的资源以避免泄露 golang内存泄露

本文是对《100 Go Mistackes：How to Avoid Them》一书的翻译。因翻译水平有限，难免存在翻译准确性问题，敬请谅解。关注公众号 “Go学堂”，获取更多系列文章

众所周知，计算机的资源（内存、磁盘）都是有限的，在编程时，这些资源必须在代码的中的某个地方被关闭释放，以避免造成资源不足而泄露。但开发人员在编写代码时往往会忽略关闭已打开的资源，从而因资源不足导致程序出现异常。
本文主要介绍在Go中，凡是实现了io.Closer接口的结构体，最终都必须要被关闭以释放资源。
下面这个例子是一个getBody函数，该函数会构建一个HTTP GET请求并处理得到的HTTP响应。
下面是第一版本的实现：

func getBody(url string) (string, error) { resp, err := http.Get(url) if err != nil { return "", err } body, err := ioutil.ReadAll(resp.Body) ① if err != nil { return "", err } return string(body), nil }

① 读取resp.Body并将其转换成一个字节数组[]byte
我们使用了http.Get方法，然后我们使用ioutil.ReadAll解析响应值。这个函数的功能看起来算是正常的。至少，它正确返回了HTTP响应。
然而，这里存在一个资源泄露的问题。让我们看看是在哪里。
resp是一个*http.Response指针类型。它包含一个io.ReaderCloser字段（io.ReadCloser同时包含io.Reader接口和io.Closer接口）。如果http.Get没有返回错误，那该字段必须被关闭。否则，就会造成资源泄露。它会占用一些内存，这些内存在函数执行后就不再需要了，但因没有主动释放资源所以不能被GC回收，同时在资源匮乏的时候客户端还不能重用TCP连接。
处理该主体关闭的最方便的方法就是使用defer语句：

func getBody(url string) (string, error) { resp, err := http.Get(url) if err != nil { return "", err } defer resp.Body.Close() ① body, err := ioutil.ReadAll(resp.Body) if err != nil { return "", err } return string(body), nil }

① 如果http.Get没有返回错误，我们会使用defer来关闭响应值。
在该实现中，我们使用延迟函数（defer）正确处理了关闭返回资源，这样一旦getBody函数返回该延迟关闭语句就会被执行。

注意：我们应该消息resp.Body.Close()返回错误。我们在错误管理一章将会看到在延迟函数中如何处理错误。在这个例子以及后续的例子中，我们将暂时忽略错误。

我们应该注意的是无论我们是否从response.Body中读取到内容，我们都需要把响应资源关闭。
例如，在下面的函数中我们仅返回了HTTP状态码。然而，响应体也必须被关闭：

func getStatusCode(url string) (int, error) { resp, err := http.Get(url) if err != nil { return 0, err } defer resp.Body.Close() ① return resp.StatusCode, nil }

① 即使没读取内容，响应体也需要被关闭。
我们应该确保在正确的时刻释放掉资源。例如，如果不考虑error的类型就延迟调用resp.Body.Close():

func getStatusCode(url string) (int, error) { resp, err := http.Get(url) defer resp.Body.Close() ① if err != nil { return 0, err }return resp.StatusCode, nil }

① 在该阶段，resp可能是nil
因为resp可能是nil，所以这段代码可能会导致程序panic：

panic: runtime error: invalid memory address or nil pointer dereference

【释放有限的资源以避免泄露】最后一件关于HTTP请求体关闭需要注意的事情。一个非常少见的情况，就是如果响应是空，而非nil时关闭响应：

resp, err := http.Get(url) if resp != nil { ① defer resp.Body.Close() ② } if err != nil { return "", err }

① 如果response不是nil
② 作为延迟函数关闭响应体
该实现使错误的。该实现依赖一些条件（例如，重定向失败），resp和err都不是nil。
然而，依据Go官方文档所说：出现错误时，任何都可以被忽略掉。一个返回非nil错误的非nil响应只有当CheckRedirect失败时才会出现，然而，这时返回的Response.Body已经被关闭了。
因此，if resp != nil {}的检查语句是没必要的。我们应该坚持最初的解决方案，只有在没有错误的情况下才在延迟函数中关闭主体。

注意：在服务端，当实现一个HTTP handler时，不必关闭请求，因为它会被服务器自动关闭。

关闭资源以避免泄露不仅仅和HTTP的响应体有关。通常来说，所有实现了io.Closer接口的结构体都需要在某个时刻被关闭。该接口包含唯一的一个Close方法：

type Closer interface { Close() error }

让我们看一些其他关于资源需要被关闭而避免泄露的例子：
2.9.1 sql.Rows
sql.Rows是用于sql查询结果的结构体。因为该结构体实现了io.Closer接口，所以它必须被关闭。我们也可以像下面这样使用延迟函数来处理关闭逻辑：

db, err := sql.Open("postgres", dataSourceName) ① if err != nil { return err } rows, err := db.Query("SELECT * FROM MYTABLE") ② if err != nil { return err } defer rows.Close() ③// Use rows

① 创建一个SQL连接
② 执行一个SQL查询
③ 关闭 rows
如果Query的调用没有返回错误，那我们就需要及时的关闭rows。
2.9.2 os.File
os.File代表一个打开的文件标识符。和sql.Rows一样，最终也应该的被关闭：

f, err := os.Open("events.log") ① if err != nil { return err } defer f.Close() ②// Use file descriptor

① 打开文件
② 关闭文件标识符
当所在的函数块返回时我们又一次使用defer来调度Close方法。

注意：正在关闭的文件不会保证文件内容已经被写到磁盘上。事实上，写
入的内容可能留在了文件系统的缓冲区上，还没有被刷新到磁盘上。如果
持久化是一个关键因素，我们应该使用Sync()方法来把缓冲区上的内容刷
到磁盘上。

2.9.3 压缩实现
压缩的写入和读取实现也需要被关闭的。事实上，他们创建的内部缓冲区也是需要被手动释放的。例如：gzip.Writer.

var b bytes.Buffer ① w := gzip.NewWriter(&b) ②defer w.Close() ③

① 创建一个缓冲区
② 创建一个新的gzip writer
③ 关闭 gzip.Writer
gzip.Reader具有同样的逻辑：

var b bytes.Buffer ① r, err := gzip.NewReader(&b) ② if err != nil { return nil, err }defer r.Close() ③

① 创建一个缓冲区
② 创建一个新的gzip writer
③ 关闭gzip.Writer
小结
我们已经看到，关闭有限的资源以避免泄漏是多么重要。有限的资源必须在正确的时间和特定的场景下被关闭。有时，是否需要资源不是很明确。我们只能通过阅读相关的API文档或实际实践来决定。然而，我们必须要谨慎，如果一个结构体实现了io.Closer接口，我们就必须要在最后调用Close方法。