Python内存泄漏四大源头：全局字典缓存未清理、循环引用+__del__阻塞GC、threading.local残留、闭包捕获大对象；需分别采用LRU限容、弱引用、手动清理、参数解耦等策略防控。

全局字典缓存未清理

Python 中用 dict 做全局缓存是最常见的内存泄漏源头，尤其在 Web 服务或长时运行脚本里。缓存键没做生命周期控制、没设最大容量、没配过期策略，对象就一直挂在内存里不释放。

典型表现是：进程 RSS 内存持续上涨，gc.get_objects() 能查到大量本该被回收的实例；用 objgraph.show_most_common_types() 会看到某个业务类实例数异常高。

• 加限容：用 collections.OrderedDict 实现 LRU，或直接上 functools.lru_cache(maxsize=128)
• 避免用可变类型（如 list、dict）作缓存 key，否则哈希不稳定，导致重复缓存
• 若必须用自定义对象作 key，确保实现了 __hash__ 和 __eq__，且内容不可变

循环引用 + 自定义 __del__

当两个对象互相持有对方引用，又都定义了 __del__ 方法，Python 的循环垃圾回收器（GC）会放弃清理它们——因为无法确定析构顺序，怕调用出错。这些对象就永久滞留在 gc.garbage 里。

常见于事件回调、观察者模式、数据库连接池中：A 持有 B 的回调函数，B 又通过闭包引用 A，再加个 __del__ 收尾逻辑，就锁死了整条引用链。

• 优先用弱引用替代强引用：把回调注册改为 weakref.WeakKeyDictionary 或 weakref.ref(callback)
• 彻底避免在关键路径写 __del__；改用上下文管理器（__enter__/__exit__）或显式 close() 方法
• 定期检查：import gc; gc.collect(); print(gc.garbage)，一旦非空就要排查

线程局部存储（threading.local）残留

threading.local 看似“线程私有”，但 Python 实际是靠线程 ID 查字典实现的。线程退出后，如果主线程或线程池没主动清理，对应字典项不会自动消失，尤其在使用 concurrent.futures.ThreadPoolExecutor 时容易积累。

现象是：多线程服务跑久了，每个线程的 local 对象（比如 DB 连接、日志 handler）不断增生，sys._current_frames() 查不到，但 gc.get_objects() 能扫出大量未释放实例。

• 不要依赖线程自然退出来清理；在线程任务末尾手动删掉 local 属性：del threading.local().xxx
• 改用更可控的方案：函数参数传入依赖，或用 contextvars.ContextVar（Python 3.7+），它随协程/任务生命周期自动管理
• 若必须用 threading.local，可在 executor 的 initializer 和 finalizer 中统一管理初始化与清空

闭包捕获大对象未释放

闭包函数会隐式持有

外层作用域的所有变量，哪怕只用其中一个小字段。如果外层有个大 list、pandas.DataFrame 或文件句柄，而闭包只用来取一个配置值，整个大对象仍无法被回收。

这种泄漏隐蔽性强，objgraph.find_backref_chain() 往往指向一个匿名函数，溯源困难。

• 显式解耦：把需要的值提前取出，传给闭包作为参数，而不是让它捕获整个作用域
• 用 functools.partial 替代闭包，它只绑定指定参数，不捕获自由变量
• 调试时打印 func.__code__.co_freevars 和 func.__closure__，确认闭包实际绑定了哪些对象

真正难处理的不是单点泄漏，而是多个小泄漏叠加后触发 GC 阈值升高、延迟回收，让问题变得间歇且难以复现。建议在关键服务启动时设置 gc.set_debug(gc.DEBUG_UNCOLLECTABLE)，并配合 tracemalloc 定期快照比对。