1 现象

在开发一个多进程计算任务执行脚本时，通过 Linux 监控发现，负责 执行计算 的进程的内存占用会迅速增长，从每个进程不到 1GiB 迅速增加到每个进程 18GiB 左右，然后逐渐稳定在 14GiB - 20GiB。

使用 tracemalloc 库监控 执行计算 的进程的内存占用。具体地，在 执行计算 的进程启动时，初始化监控（tracemalloc.start()），在每个任务计算完成时，打印当前内存占用和内存峰值（tracemalloc.get_traced_memory()）。通过 tracemalloc 的监控，可以发现：

• 启动阶段：执行一个计算任务的进程的内存峰值基本不超过 2GiB；
• 内存增长阶段：任务计算完成时内存占用均会逐渐增加而不会减少，每个任务计算完成后平均增加 100MiB - 200MiB 左右，内存峰值也随之增加，但内存占用和内存峰值之间的差距相对固定；
• 内存稳定阶段：内存占用增加到 14GiB - 20GiB 后，内存占用开始波动，并逐渐稳定在 14GiB - 20GiB；

以上发现与 Linux 监控的进程内存占用相匹配。

2 原因推断

根据使用 tracemalloc 库监控的发现，可以将已知情况整理如下：

• 每个任务会有约 100MiB - 200MiB 左右的内存无法被释放；
• 当累计有 70 - 200 个计算任务的内存无法被正常释放后，后续的内存释放开始正常（很有可能是最早的任务开始被释放）。

根据已知情况确定：一定存在未能及时被引用计数机制回收的对象

因为内存占用在不断增加后，可以稳定在 14GiB - 20GiB 左右，所以说明垃圾回收机制仍然是可以生效的，但是存在某个问题，使只有当内存占用达到一定数量之后才会触发垃圾回收。因此，推断如下：

• 因为引用计数机制是即时的，当对象的引用计数为 0 后就会被立即回收，所以说明 一定存在未能及时被引用计数机制回收的对象；
• 如果存在无法被 “标记 - 清除” 机制回收的对象，那么内存占用不会最后稳定在 14GiB - 20GiB 之间，所以 一定不存在无法被 “标记 - 清除” 机制回收的对象。

根据已知情况推断：引用计数未及时归 0，或 “标记 - 清除” 机制未正常触发

进而，推断有两种可能如下：

• 存在短时间内引用计数不为 0（无法被引用计数机制回收）且可达（无法被标记 - 清除机制回收）的对象，当内存占用达到 14GiB - 20GiB 时，其中部分对象的引用计数变为 0 或变得不可达。
• “标记 - 清除” 机制未不正常触发，只有当内存占用达到 14GiB - 20GiB 左右才被触发。

添加 gc.collect() 及打印 gc.get_count() 验证：排除 “标记 - 清除” 机制未正常触发的可能性

在 执行计算 的进程启动时，使用 gc.get_threshold() 打印了三代对象计数器的阈值，发现为默认值 (700, 10, 10)；在每个任务计算完成后：

• 添加 gc.collect() 进行显示的垃圾回收，发现内存占用的增长速度没有变化；
• 使用 gc.get_count() 打印当前三代对象的数量，发现均为 (6, 0, 0) 或 (8, 0, 0)，但内存占用在显著增长。

通过上述验证：因为手动触发 “标记 - 清除” 机制的垃圾回收对内存占用的增长没有影响，又因为三代对象的数量没有累加而内存占用在不断增加；所以共同验证了不是因为 “标记 - 清除” 机制未不正常触发导致的内存占用不断增加。

综上所述，当前内存泄露只剩下了一种可能：存在短时间内引用计数不为 0（无法被引用计数机制回收）且可达（无法被标记 - 清除机制回收）的对象，当内存占用达到 14GiB - 20GiB 时，其中部分对象的引用计数变为 0 或变得不可达。

3 定位内存泄漏位置

使用 tracemalloc 库按行统计内存占用情况。具体地：

for statistic in tracemalloc.take_snapshot().statistics("lino"):if statistic.size > 1024 * 1024:print(statistic)

其中：

• statistic.size 的类型为 int，单位为 B，表示该文件占用的内存总量；
• statistic.count 的类型为 int，表示该文件创建的对象数量；
• statistic.average 的类型为 int，表示平均每个对象占用的内存数量。

发现内存占用最多的行是：../python3.8/site-packages/numpy/core/numeric.py:314，即 numpy 矩阵构造逻辑所在位置。

在每个任务计算完成后，count 会增加 7，内存占用增加 average 在 20MiB 左右，与每个任务计算完成后内存占用增加 100MiB - 200MiB 相匹配，说明绝大多数的内存占用均为 numpy 矩阵。

因为在 执行计算 的进程中仅有读取数据后构造的数据对象中会生成较多 numpy 矩阵，又因为其他内存占用较多的行均为构造数据对象时的逻辑，所以，基本可以确定是 数据对象 或者 数据对象的构造器 没有被按时销毁导致的内存泄露。

于是，在 数据对象 或者 数据对象的构造器 的 __del__() 方法中添加日志打印，检查对象是否被销毁。运行测试后发现，数据对象的构造器 在每次任务计算中均被正常销毁，但是 数据对象 未被及时销毁。

综上所述，当前内存泄露已定位到：数据对象 在计算任务结束后，引用计数不为 0 且可达，无法被垃圾回收机制回收。

4 定位内存泄露原因

这说明，数据对象 在除了计算调度的逻辑外，还在其他位置存在引用，且在计算完成后，该引用未被销毁。于是，通过在 数据对象 构造完成后至任务计算完成前添加注释，使用 sys 包的 sys.getrefcount() 方法打印 数据对象 的引用计数，发现引用计数的增加与使用 lru_cache 的数量一致。

在发现了 lru_cache 的使用场景后发现，数据对象 中的部分方法为实现属性的懒惰计算使用了 lru_cache。但是，lru_cache 在缓存实例的方法时，需要存储方法所属的实例，这就导致每次使用不同方法 lru_cache，都会使 数据对象 的引用计数会加 1，从而导致 数据对象 在生命周期结束后，仍然在 lru_cache 中保留了引用，无法被及时销毁。

lru_cache 的默认大小为 128，因此，当一共缓存满 128 个计算任务后，lru_cache 会释放掉最早缓存的 数据对象，从而使该 数据对象 的引用计数归 0，得到释放。因为平均每个任务占用内存约为 100MiB - 200MiB，所以缓存满 128 个计算任务后，内存占用会在 14GiB - 20GiB 左右波动。

5 内存泄露的解决

将 lru_cache 改为使用实例属性进行缓存，或将 lru_cache 的大小改为 1 后，内存峰值固定在 2GiB 左右，任务计算完成后的内存占用稳定在 0.001GiB - 0.002GiB，问题解决。