关于Python内存泄漏问题的排查与解决方法

关于Python内存泄漏，核心是排查循环引用和全局变量。直接上干货，用objgraph和gc模块来定位问题。

1. 基本排查工具

import gc
import objgraph

# 强制垃圾回收并查看对象数量
gc.collect()
print(gc.garbage)  # 查看无法回收的对象

# 统计指定类型的对象数量
objgraph.show_most_common_types(limit=20)

2. 定位循环引用

class Node:
    def __init__(self, name):
        self.name = name
        self.parent = None
        self.children = []

# 创建循环引用
root = Node("root")
child = Node("child")
root.children.append(child)
child.parent = root  # 循环引用形成

# 删除引用后对象依然存在
del root
del child

# 查找循环引用
gc.collect()
for obj in gc.garbage:
    print(f"无法回收: {type(obj).__name__}")

# 用objgraph可视化引用关系（需要安装graphviz）
objgraph.show_backrefs([obj], filename="leak.png")

3. 使用weakref打破循环

import weakref

class NodeFixed:
    def __init__(self, name):
        self.name = name
        self.parent = None  # 普通引用
        self.children = []
    
    def set_parent(self, parent):
        # 对父节点使用弱引用
        self.parent = weakref.ref(parent)

4. 检查全局变量和缓存

# 常见泄漏点：模块级缓存
_cache = {}

def process_data(data):
    # 缓存无限增长导致泄漏
    if data not in _cache:
        _cache[data] = expensive_computation(data)
    return _cache[data]

# 改进：使用LRU缓存或设置上限
from functools import lru_cache

@lru_cache(maxsize=128)
def process_data_fixed(data):
    return expensive_computation(data)

5. 监控内存增长

import tracemalloc

tracemalloc.start()

# ...执行可疑代码...

snapshot = tracemalloc.take_snapshot()
top_stats = snapshot.statistics('lineno')

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

排查步骤总结：

1. 用gc.collect()和gc.garbage看是否有无法回收的对象
2. 用objgraph找出引用最多的对象类型
3. 检查自定义类中的双向引用，用weakref改造
4. 审查全局字典、缓存等长期持有引用的地方
5. 用tracemalloc定位内存增长的具体代码行

一句话建议：重点检查循环引用和全局缓存，用objgraph可视化引用关系最直接。

你实际用的内存主要是看 RSS
如果你对性能要求很高 可以假装…无视如此庞大的 VSIZE(减少线程数也能降低)

MALLOC_ARENA_MAX 调小之后 会增大 memory congestion 的几率, tcmalloc 等能视觉上降低 VSIZE 也只是算法做了优化, 使用了更效率的 lock/unlock 机制.

默认 glibc 在线程初始化的时候会固定分配一块大约 100M 的内存, 但因为他没被使用 所以它只是 VSIZE
如果你有 20 个线程 每个实际用 1M 的内存
那么结果(使用 glibc 的默认设置)就是 20M 的 RSS 2G 的 VSIZE

设置了这个值好像没用，内存今天又开始慢慢增加了
查了一篇文章说在 redhat 6，glibc 2.12 版本上面设置这个值是无效的（ glibc 的 bug ）
—>https://yq.aliyun.com/articles/227924，

不知道是不是这个原因，如果是的话只有升级系统版本到 centos7 了

pmap -x 2473 | sort -nk 2 | grep anon
00007fb4c3fff000 4 0 0 ----- [ anon ]
00007fb4e17fc000 4 0 0 ----- [ anon ]
00007fb4e21fd000 4 0 0 ----- [ anon ]
00007fb4e2bfe000 4 0 0 ----- [ anon ]
00007fb4e35ff000 4 0 0 ----- [ anon ]
00007fb4fc3fa000 4 0 0 ----- [ anon ]
00007fb4fcdfb000 4 0 0 ----- [ anon ]
00007fb4fd7fc000 4 0 0 ----- [ anon ]
00007fb4fe1fd000 4 0 0 ----- [ anon ]
00007fb4febfe000 4 0 0 ----- [ anon ]
00007fb4ff5ff000 4 0 0 ----- [ anon ]
00007fb503fff000 4 0 0 ----- [ anon ]
00007fb504993000 4 0 0 ----- [ anon ]
00007fb505394000 4 0 0 ----- [ anon ]
00007fb507be5000 4 4 4 rw— [ anon ]
00007fb50864f000 4 0 0 rw— [ anon ]
00007fb511cc7000 4 4 4 rw— [ anon ]
00007fff29bff000 4 4 0 r-x-- [ anon ]
ffffffffff600000 4 0 0 r-x-- [ anon ]
00007fb507dfe000 8 4 4 rw— [ anon ]
00007fb511cc3000 8 8 8 rw— [ anon ]
00007fb509160000 16 16 16 rw— [ anon ]
00007fb510e53000 16 16 16 rw— [ anon ]
00007fb5116fb000 16 4 4 rw— [ anon ]
00007fb511a97000 56 56 56 rw— [ anon ]
00007fb4d4000000 132 36 36 rw— [ anon ]
00007fb5063a5000 260 256 256 rw— [ anon ]
00007fb506b45000 260 256 256 rw— [ anon ]
00007fb511c38000 540 532 532 rw— [ anon ]
00007fb4c8000000 584 144 144 rw— [ anon ]
00007fb5048d2000 772 772 772 rw— [ anon ]
00007fb4d8000000 856 552 552 rw— [ anon ]
00007fb4dc000000 1020 776 776 rw— [ anon ]
00007fb4f4000000 1028 1028 1028 rw— [ anon ]
00007fb511b02000 1040 1024 1024 rw— [ anon ]
00007fb4f8000000 1048 808 808 rw— [ anon ]
00007fb4d0000000 1184 944 944 rw— [ anon ]
00007fb4e4000000 1272 1040 1040 rw— [ anon ]
00007fb5067ee000 1292 1284 1284 rw— [ anon ]
00007fb4ec000000 1296 1296 1296 rw— [ anon ]
00007fb4f0000000 1520 1284 1284 rw— [ anon ]
00007fb4e8000000 1772 1544 1544 rw— [ anon ]
0000000001476000 3216 3100 3100 rw— [ anon ]
00007fb5040cb000 6148 6148 6148 rw— [ anon ]
00007fb4e0efa000 9224 9224 9224 rw— [ anon ]
00007fb4e17fd000 10240 20 20 rw— [ anon ]
00007fb4e21fe000 10240 20 20 rw— [ anon ]
00007fb4e2bff000 10240 20 20 rw— [ anon ]
00007fb4e3600000 10240 2048 2048 rw— [ anon ]
00007fb4fc3fb000 10240 20 20 rw— [ anon ]
00007fb4fcdfc000 10240 20 20 rw— [ anon ]
00007fb4fd7fd000 10240 20 20 rw— [ anon ]
00007fb4fe1fe000 10240 20 20 rw— [ anon ]
00007fb4febff000 10240 20 20 rw— [ anon ]
00007fb4ff600000 10240 2048 2048 rw— [ anon ]
00007fb504994000 10240 20 20 rw— [ anon ]
00007fb505395000 10240 48 48 rw— [ anon ]
00007fb4c4000000 19984 19024 19024 rw— [ anon ]
00007fb4c5384000 45552 0 0 ----- [ anon ]
00007fb4e81bb000 63764 0 0 ----- [ anon ]
00007fb4f017c000 64016 0 0 ----- [ anon ]
00007fb4ec144000 64240 0 0 ----- [ anon ]
00007fb4e413e000 64264 0 0 ----- [ anon ]
00007fb4d0128000 64352 0 0 ----- [ anon ]
00007fb4f8106000 64488 0 0 ----- [ anon ]
00007fb4f4101000 64508 0 0 ----- [ anon ]
00007fb4dc0ff000 64516 0 0 ----- [ anon ]
00007fb4d80d6000 64680 0 0 ----- [ anon ]
00007fb4c8092000 64952 0 0 ----- [ anon ]
00007fb4d4021000 65404 0 0 ----- [ anon ]
00007fb4c0000000 65532 65532 65532 rw— [ anon ]
00007fb500000000 65532 65532 65532 rw— [ anon ]

这个是 Python 进程的内存使用情况(anon)

我看了下 /proc/meminfo , 感觉 Slab + AnonPages + python 进程的 RES 内存 = 系统的真实使用内存，不知道这么算对不对？

下面是 slabtop 的结果，dentry 不知道是干啥用的
<img src=" " />