利用Python gc模块识别与修复内存泄漏问题

既然已经排除了__del__方法的问题，那可以通过以下步骤用gc模块定位循环引用导致的泄漏：

• 开启gc调试模式，捕获泄漏对象
  运行程序前设置gc.set_debug(gc.DEBUG_LEAK)，这个参数会开启多种调试日志，包括记录无法被回收的对象，同时会把这些对象存入gc.garbage列表。程序运行一段时间后，直接查看这个列表就能拿到所有泄漏的对象实例。

• 梳理对象的引用链
  针对gc.garbage里的对象，用gc.get_referrers(obj)查看哪些对象还在引用它，用gc.get_referents(obj)查看这个对象引用了哪些其他对象。通过这两个方法可以清晰梳理出循环引用的具体链路，找到哪两个（或多个）对象互相持有强引用导致无法回收。

• 统计特定类的实例数量变化
  用gc.get_objects()获取当前所有被gc管理的对象，然后筛选出你关注的类实例：

  target_class = YourCustomClass
  instance_count = len([obj for obj in gc.get_objects() if isinstance(obj, target_class)])
  

  在程序运行的不同阶段（比如启动后、处理完一批任务后）统计这个数量，如果持续增长且没有回落，基本可以确认该类存在泄漏。

• 手动触发gc并验证回收效果
  有时候自动gc的触发时机可能滞后，手动调用gc.collect()强制回收，之后再检查gc.garbage和实例数量的变化。如果调用后实例数量没有明显减少，说明这些对象确实被循环引用或其他强引用锁住了。

针对长期运行的Python应用，这些实践能有效避免内存泄漏和内存占用过高：

• 用弱引用打破循环引用
  对于不需要强引用的对象关联（比如缓存中的键值对、对象间的非必要关联），用weakref模块的ref、WeakKeyDictionary或WeakValueDictionary，这类弱引用不会阻止gc回收对象，从根源上避免循环引用导致的泄漏。

• 监控内存和gc状态
  定期用gc.get_stats()查看gc的回收次数、回收对象数量等统计数据；用psutil模块实时监控进程的内存占用，设置阈值报警，一旦内存超过预警值就触发排查。

• 限制全局变量的使用
  全局变量的生命周期和程序一致，不要把大量临时对象或业务数据存在全局变量里。优先用局部变量，或者用有明确生命周期的容器（比如函数内的变量、类实例的属性，在实例销毁时会被回收）。

• 用上下文管理器管理资源
  对于需要手动清理的对象（比如文件句柄、网络连接、自定义资源对象），实现__enter__和__exit__方法，通过with语句确保使用后及时释放资源，避免对象被意外持有导致无法回收。

• 给缓存设置边界
  如果使用缓存（比如functools.lru_cache），一定要设置maxsize限制缓存的最大容量；或者用带淘汰策略的缓存库（比如cachetools的TTLCache），避免缓存无限增长占用内存。

• 避免循环中创建大量临时对象
  尽量复用对象，比如用列表推导代替循环中反复创建临时列表；用生成器表达式代替列表，减少内存占用；对于频繁创建的对象，考虑用对象池模式复用实例。

• 分模块测试内存泄漏
  在开发阶段就对单个模块做内存测试，比如在单元测试中加入实例数量统计，确保每个模块在多次调用后内存能正常回收，避免集成后才排查泄漏点。

内容的提问来源于stack exchange，提问作者Arslan Ahmad