1. 背景

前段时间接手了一个边缘视觉识别的项目，大功能已经开发的差不多了，主要是需要是优化一些性能问题。其中比较突出的内存泄漏的问题，而且不止一处，有些比较有代表性，可以总结一下。

为了更好地可视化内存占用的变化，将项目占用的机器资源指指标上报到 Prometheus，项目一开始的情况如下（横轴-时间，纵轴-内存）：

可以看到内存在不断的增长，到最后 OOM 了，服务重启，确实有内存泄漏的情况。

2. 工具

• Memray
• Tracemalloc
• Memory_profiler

3. 查看是否有线程数泄漏

使用 Memray 查看线程的占用情况，可以看到线程数一直在增长

新增加的线程大部分都是 sockerserver，我查了下，大概率是 SSE 的连接没有释放掉，再看看代码：

   def sse_server(self):
        def streamer():
            while True:
                try:
                    # do yield
                    ...
                except:
                    ...


        response = Response(streamer(), mimetype="text/event-stream")
        response.headers["Cache-Control"] = "no-cache"
        response.headers["X-Accel-Buffering"] = "no"
        return response

如上图看到：try 在 while 里面，如果遇到所有异常，会被 try catch 到，循环并不会结束，如果没有适当的退出机制，这会导致永远也无法结束，资源一直没释放。

解决方案，考虑更全面一些，除了特定的异常，其他的异常都必须中断循环。

def sse_server(self):
    def streamer():
        while True:
            try:
                # 生成事件数据
                data = yield
                # 这里可以添加生成数据的逻辑
            except AllowException:
                # 期待的，能继续生成数据的异常
                continue
            except GeneratorExit:
                # 客户端连接关闭时退出生成器
                break
            except Exception as e:
                # 其他异常处理
                break


    def generate():
        for message in streamer():
            if message:
                yield f"data: {message}\n\n"


    response = Response(generate(), mimetype="text/event-stream")
    response.headers["Cache-Control"] = "no-cache"
    response.headers["X-Accel-Buffering"] = "no"
    return response

本以为已经解决了内存泄漏的问题，没想到一看 prom，内存还是在一直增长，说明还有其他的内存泄漏。

4. 检查依赖 C++ 动态库的代码

这个项目是需要对视频流解码，其中也用到了 ffmpeg 的库，有一部分代码是使用 C++ 写的，这部分需要手动管理内存，这部分管理不好，也会导致内存泄漏。

我把所有申请到内存的都看了一遍，结果发现有网络初始化，没有对应的网络释放，avformat_network_init 和 avformat_network_deinit 函数是成对使用的，avformat_network_deinit 用于关闭网络模块并释放相关资源。如果在程序结束时没有调用这个函数，可能会导致与网络相关的资源没有被正确释放，从而产生内存泄漏。

但这个是在网络不稳定的情况下，一直频繁地断开，重新创建解码线程，内存泄漏才会显现出来，一般在内部，网络稳定的情况下，问题不大。果然，编译完重新跑，内存泄漏还没有解决。

5. 使用 tracemalloc 查看内存增长

import tracemalloc
tracemalloc.start()
# ... 开始程序 ...


snapshot1 = tracemalloc.take_snapshot()
# ... 怀疑有泄漏的代码 ...
snapshot2 = tracemalloc.take_snapshot()


top_stats = snapshot2.compare_to(snapshot1, 'lineno')


for stat in top_stats[:10]:
    print(stat)

跑了2个小时后，发现某一行的内存一直没有释放，count 和 size 一直在增加，并没有释放的迹象。

analyzer_arm_rknn_4.py:397: size=3318 KiB (+18.6 MB), count=39426 (+10), average=501 K

所以读了这部分相关的代码，代码的逻辑大概是：拷贝一张图片，并且再一张图片画框，然后将这张图片发送给上级系统，并将这张图片和信息持久化到自研的文件系统中。

看调试信息，大概率是这张图片内存没有被释放，在 Python 中，如果没有被释放，说明这张图片的引用计数大于 0，一直被某个地方引用到了。过程我就不细聊了，最终发现下面的代码有问题：

    def write_disk(self, force=False):
        t = time.time()


        if self.buffer["total_size"] == 0:
            ...


        elif self.buffer["total_size"] > BUFFER_SIZE or t - self.buffer["t"] > BUFFER_INTERVAL or force:
            ...
            self.buffer["t"] = t
            self.buffer["total_size"] = 0
            try:
                f = open(self.save_path, "rb+")
                for item in self.buffer["tasks"]:
                    item["call"](f, *item["args"])
                f.close()
            except Exception:
                logger.debug(traceback.format_exc())

大概意思是：这张图片先写到缓存中，在缓存超过一定大小或超过一定时间后或force参数为true时，会被写到磁盘中。虽然buffer 的时间和总大小都重新初始化了，但是占比最大的 self.buffer["tasks"] 并没有重置，这个导致图片一直被缓存到 buffer 中没有被释放。

最终封装到 reset_buffer，一起重启，避免忘记重置：

  def reset_buffer(self, t):
     self.buffer["t"] = t
     self.buffer["total_size"] = 0
     self.buffer["tasks"] = []
  def write_disk(self, force=False):
        t = time.time()


        if self.buffer["total_size"] == 0:
            ...


        elif self.buffer["total_size"] > BUFFER_SIZE or t - self.buffer["t"] > BUFFER_INTERVAL or force:
            ...
            try:
                f = open(self.save_path, "rb+")
                for item in self.buffer["tasks"]:
                    item["call"](f, *item["args"])
                f.close()
            except Exception:
                logger.debug(traceback.format_exc())
            self.reset_buffer(t)

这波改完，信心满满，感觉应该彻底解决了。重新跑 了大概1天左右，再抽空看了 prom 内存增长曲线，曲线的斜率变低了（我的心率变高了），说明有效，但没有彻底解决，还得再查.......

6. 重复上面的操作，再看看哪个变量没有被释放

经过一系列的排查，最终发现“嫌疑人“

video_fetcher_2.py:273: size=20.4 MB (+496 kB), count=19082 (+2)  

273 这代码也缓存相关的代码，大概逻辑是将 h264 的视频流添加到缓存，等到一定是条件再写到磁盘。

  if self.record_task:
      with self.record_task_mtx:
         ....
         if self.record_task["now_sec"] == self.record_task["end_sec"] + 1:
             # write disk
             self.record_task = None

因为now_sec不一定是end_sec + 1，也可能是因为网络或者跳过的原因，导致 now_sec 大于 end_sec。所以不能严格地用 +1 来判断。

可以改成“大于等于”， 应该就解决了：

  if self.record_task:
      with self.record_task_mtx:
         ....
         if self.record_task["now_sec"] >= self.record_task["end_sec"] + 1:
             # write disk
             self.record_task = None

接下来跑了1天，基本上能回到原来的位置（横轴-时间，纵轴-内存）：

7. 总结

通过1个项目，我们可以遇到 Python 项目中的几种内存没有释放的例子：

• Python 依赖的资源库没有释放内存
• 使用缓存时，确认过期后没有释放内存
• 缓存的过期条件有问题，没有触发
• 线程没有释放

解决方案：

• 没有 GC 的语言，一定要检查申请的资源是否有释放
• 使用线程或者进程时，尽量使用线程池或进程池
• 在使用缓存时，一定要检查缓存的过期条件
• 尽量监控资源指标，尽量在上线前发现问题

当然我并没有要抨击之前写代码的人，写这篇文章只是为了总结下内存泄漏