内存未释放回操作系统

在Golang实战开发的过程中，我们经常会遇到一些这样那样的问题，然后要卡好半天，等问题解决了才发现原来一些细节知识点还是没有掌握好。今天golang学习网就整理分享《内存未释放回操作系统》，聊聊，希望可以帮助到正在努力赚钱的你。

我创建了一个图像调整大小服务器，它可以为您上传到其中的图像创建一些不同的缩略图。我使用 https://github.com/h2non/bimg 包来调整大小，该包使用带有 c 绑定的 libvips。

在投入生产之前，我开始使用 jmeter 对我的应用程序进行压力测试，并同时向其上传 100 个图像，并先后多次上传，并注意到内存没有被释放回操作系统。

为了说明这个问题，我编写了几行代码来读取 100 个图像并调整它们的大小（不将它们保存在任何地方），然后等待 10 分钟。如此重复5次

我的代码和内存/CPU 图表可以在这里找到： https://github.com/hamochi/bimg-memory-issue

很明显，内存在每个周期都被重用，否则它应该增加一倍（我认为）。但它永远不会释放回操作系统。

这是 cgo 的普遍行为吗？或者 bimg 正在做一些奇怪的事情。或者只是我的代码有问题？

非常感谢您提供的任何帮助！

解决方案

有一个 libvips 可以跟踪和调试引用计数——你可以尝试启用它，看看是否有任何泄漏。

https://libvips.github.io/libvips/API/current/libvips-vips.html#vips-leak-set

虽然从您上面关于 bimg 内存统计数据的评论来看，听起来可能一切都很好。

从 python 测试 libvips 内存很容易。我做了这个小程序：

#!/usr/bin/python3

import pyvips
import sys

# disable libvips operation caching ... without this, it'll cache all the
# thumbnail operations and we'll just be testing the jpg write
pyvips.cache_set_max(0)

for i in range(0, 10000):
    print("loop {} ...".format(i))
    for filename in sys.argv[1:]:
        # thumbnail to fit 128x128 box
        image = pyvips.image.thumbnail(filename, 128)
        thumb = image.write_to_buffer(".jpg")

即。重复缩略图一组源图像。我是这样运行的：

$ for i in {1..100}; do cp ~/pics/k2.jpg $i.jpg; done
$ ../fing.py *

并观看了顶部的 res。我看到：

loop | RES (kb)
  -- | --
 100 | 39220
 250 | 39324
 300 | 39276
 400 | 39316
 500 | 39396
 600 | 39464
 700 | 39404
1000 | 39420

只要您没有引用计数泄漏，我认为您所看到的就是预期的行为。 linux 进程只能将堆末尾的页面释放回操作系统（看看 brk 和 sbrk sys 调用）：

https://en.wikipedia.org/wiki/Sbrk

现在想象一下，如果 1) libvips 分配 6gb，2) go 运行时分配 100kb，3) libvips 释放 6gb。你的 libc（进程中代表你调用 sbrk 和 brk 的东西）无法将 6gb 返回给操作系统，因为堆末尾有 100kb 分配。某些 malloc 实现比其他实现具有更好的内存碎片行为，但默认的 linux 实现相当不错。

实际上，这并不重要。 malloc 会重用内存空间中的漏洞，即使不这样做，它们也会在内存压力下被调出页面，并且最终不会占用 ram。尝试运行您的进程几个小时，然后观看 res。您应该看到它缓慢上升，但随后稳定下来。

（我根本不是核心人，以上只是我的理解，当然非常欢迎指正）

今天关于《内存未释放回操作系统》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！