检测PyQt应用程序内存泄漏的最佳方法是什么

针对5×24小时运行的传感器数据记录类PyQt应用，按以下优先级排查检测，能覆盖99%的内存泄漏场景：

前置排查：先堵PyQt特有高频泄漏点 #

80%的PyQt内存泄漏都是固定场景的低级问题，先自查完再上工具，省一半时间：

• 检查所有QObject、QWidget派生类实例是否正确绑定parent：Qt的对象树自动回收机制完全依赖parent绑定，实时图表的曲线对象、临时弹窗、数据库查询游标、单次触发的QTimer这类高频创建的对象，如果没绑parent又被闭包、信号槽引用勾住，Python GC和Qt回收机制都触达不到，必漏。
• 排查非Python托管的资源泄漏：QSqlQuery未执行finish、频繁新增绘图曲线不删除旧实例、QPixmap/QImage等原生资源未手动释放的问题，Python的GC管不到Qt C++层的内存分配，这类泄漏不会在Python对象统计里体现，只会体现在进程RSS持续上涨。
• 检查信号槽绑定：尤其是跨线程的传感器数据信号、绑定lambda作为槽函数的场景，对象销毁前必须断开对应信号，否则闭包持有的对象引用会造成循环引用，永远无法回收。

常态化运行时监控（适配长稳测试要求） #

工业场景不能靠短时间调试下结论，要在测试版本内置轻量监控，连续跑数天看趋势：

• 启动时开启标准库tracemalloc，设置栈跟踪深度25，每1小时自动打内存快照，记录Top10内存分配位置、和上一小时快照的内存增量。这个模块只能跟踪Python层的内存分配，足够覆盖所有Python侧的逻辑泄漏。
• 用psutil每10分钟采集一次进程的RSS物理内存、共享内存占用，写入本地日志。判断泄漏的核心标准不是内存高，而是内存趋势：如果RSS在固定区间上下波动（GC触发时回落、数据高峰时上涨，整体基线不抬升）就属于正常；如果RSS呈线性持续上涨，哪怕每小时只涨1MB，跑满一周也会涨168MB，长期运行必然出问题。
• 每次手动触发gc.collect()后，打印本次回收的对象数量、gc.garbage列表长度。如果gc.garbage长度持续增长，说明存在带自定义__del__方法的循环引用对象，Python解释器无法自动回收。

精准定位泄漏点的工具用法 #

监控确认存在泄漏后，用对应工具快速定位根因：

• Python层泄漏用objgraph：在你怀疑泄漏的操作（比如连续刷新1000次图表、打开关闭100次数据查询窗口、连续写入1万条数据库记录）前后，分别调用objgraph.show_growth(limit=20)，直接输出两次操作之间未被回收的对象类型和增量，哪个类的实例数随操作次数线性上涨，问题点就在哪。比如连续刷100次图表发现QTimer实例多了100个，肯定是每次刷新新建定时器没释放。
• Qt C++层泄漏用Valgrind：如果监控看到RSS持续涨，但Python侧对象数没有明显增长，说明泄漏在Qt原生层。用debug版本的应用，加载Qt和Python自带的valgrind抑制文件过滤已知误报，执行命令：

  valgrind --leak-check=full --suppressions=/usr/share/qt5/valgrind/qt.supp --suppressions=python3.supp python3 your_app_entry.py
  

  跑1-2小时后看输出中标注为definitely lost的块，对应的调用栈就是未释放的原生资源位置。注意Valgrind跑起来会让应用慢10-20倍，只适合测试环境短时间定位，不要在生产环境用。
• 实时图表场景专项校验：如果你用PyQtGraph做实时曲线，连续刷新时每2小时打印一次PlotItem的子项数量，如果曲线项、坐标轴标注项的数量持续上涨，说明你在重复添加绘图元素，没有复用或删除旧元素。

工业场景长稳验证标准 #

• 做倍压长稳测试：把传感器数据上报频率调到实际生产值的2倍，连续跑72小时以上，如果RSS内存基线没有持续抬升，始终在固定区间波动，5×24运行基本不会有内存问题。
• 不要采信1小时以内的测试结果：很多泄漏单次操作只漏几KB，短时间测试完全看不出异常，跑3天以上才能看到明显的内存上涨趋势。
• 生产版本内置内存阈值告警：设置合理的RSS阈值（比如日常运行稳定占200MB，阈值设为500MB），超过阈值时打错误日志，方便现场运维提前发现异常。

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