PythonFlask内存泄漏排查指南

本文系统讲解了如何科学排查Flask应用中的内存泄漏问题，从识别典型泄漏现象（RSS持续上涨、GC无效、重启回落、与请求量正相关）入手，通过ps aux监控RES值、压测验证趋势，排除循环引用、未关闭DB连接、全局缓存等高频诱因；进而推荐memory_profiler（本地精准定位泄漏行）与tracemalloc（支持异步和线上轻量快照）双工具组合，并手把手提供可直接集成的Flask中间件代码，实现在请求级自动检测内存异常增长；特别指出gunicorn环境下worker复用会放大泄漏风险，强调需结合配置调优与根源修复——真正帮你揪出那个悄悄累积的PdfFileReader或遗忘清理的SQLAlchemy session，让性能问题无所遁形。

怎么确认Flask应用真有内存泄漏

别急着加监控工具，先看现象是否符合内存泄漏特征：进程 RSS 内存持续上涨、GC 无法回收、重启后回落、且与请求量正相关。用 ps aux --sort=-%mem | head -5 观察 flask run 或 gunicorn worker 进程的 RES 列，连续压测 10–30 分钟，每分钟记录一次；如果稳定增长（比如每千次请求涨 2–5MB），再深入排查。

注意排除干扰项：__del__ 未定义、循环引用、全局缓存未清理、数据库连接未 close、日志 handler 持有 request 上下文——这些比框架本身更容易导致泄漏。

用 memory_profiler 定位具体函数

memory_profiler 不适合线上，但对本地复现场景极有效。它能按行显示内存增量，精准锁定泄漏源头。

• 安装：pip install memory-profiler
• 在疑似泄漏的视图函数或蓝本模块顶部加装饰器：@profile（注意不是 @memory_profiler.profile，后者是旧写法）
• 用命令运行：python -m memory_profiler app.py，或配合 mprof 记录曲线：mprof run --include-children python app.py → mprof plot
• 关键看 Mem usage 列中「差值」持续为正的行，尤其是反复调用却未释放的对象创建处（如 json.loads() 后没 del、pandas.read_csv() 返回 DataFrame 未清空）

常见陷阱：@profile 只对同步函数生效；若用 async def 或 Celery 任务，需改用 tracemalloc 配合 snapshot.compare_to()。

给 Flask 加轻量中间件做请求级内存快照

不依赖外部 APM，自己写一个中间件，在每次请求前后抓取内存基线，输出异常涨幅（>5MB）的 endpoint 和峰值内存。

from flask import g, request
import tracemalloc
def init_memory_middleware(app):
tracemalloc.start(10)  # 保存 10 层调用栈
@app.before_request
def before_req():
    g.mem_before = tracemalloc.take_snapshot()

@app.after_request
def after_req(response):
    if hasattr(g, 'mem_before'):
        mem_after = tracemalloc.take_snapshot()
        top_stats = mem_after.compare_to(g.mem_before, 'lineno')
        leak_bytes = sum(stat.size_diff for stat in top_stats[:3])
        if leak_bytes > 5 * 1024 * 1024:  # 超 5MB 打日志
            app.logger.warning(
                f"High mem delta on {request.endpoint}: {leak_bytes/1024/1024:.1f}MB"
            )
    return response

这段代码必须放在 app.run() 之前调用 init_memory_middleware(app)；tracemalloc.start() 不能放在 before_request 里，否则开销过大；采样深度设为 10 是平衡精度和性能的常用值。

为什么 gunicorn + Flask 更容易漏内存

gunicorn 的 worker 复用机制会让泄漏对象跨请求存活，而开发服务器（flask run）每次请求都重建上下文，掩盖问题。

• 检查 gunicorn --max-requests 和 --max-requests-jitter：设为 1000–3000 可强制回收 worker，缓解泄漏影响（但只是掩耳盗铃）
• 禁用 preload=True：避免模块级变量（如全局 dict、单例 DB session）被所有 worker 共享并累积
• 确认 worker-class：用 sync 而非 gevent 或 eventlet，后两者因协程上下文管理更复杂，易引发隐式引用

真正要解决，得顺着中间件打的日志，找到那个 /api/report 接口里反复 new 的 PdfFileReader 实例，或者忘了 session.remove() 的 SQLAlchemy session。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《PythonFlask内存泄漏排查指南》文章吧，也可关注golang学习网公众号了解相关技术文章。