一次Python内存泄漏的真实排查经历
上周线上服务内存占用一路飙升，从200MB涨到2GB，最后OOM被系统杀了。排查过程挺曲折的，分享一下，希望帮到踩类似坑的朋友。 现象 监控告警，服务内存持续增长，重启后从200MB开始，几小时后又到2GB。典型的内存泄漏特征。 排查过程 第一步：确认是不是真的泄漏 先用tracemalloc追踪内
上周线上服务内存占用一路飙升，从200MB涨到2GB，最后OOM被系统杀了。排查过程挺曲折的，分享一下，希望帮到踩类似坑的朋友。
现象
监控告警，服务内存持续增长，重启后从200MB开始，几小时后又到2GB。典型的内存泄漏特征。
排查过程
第一步：确认是不是真的泄漏
先用tracemalloc追踪内存分配：
import tracemalloc
tracemalloc.start()# ... 运行业务代码 ...snapshot = tracemalloc.take_snapshot()
top_stats = snapshot.statistics('lineno')
for stat in top_stats[:10]:
print(stat)
输出显示某个字典对象一直在增长，占用从几MB涨到了几百MB。
第二步：定位问题代码
追了一下，发现是一个全局缓存字典没有淘汰机制：
# 问题代码：缓存只进不出
_user_cache = {}def get_user(user_id):
if user_id not in _user_cache:
_user_cache[user_id] = fetch_user_from_db(user_id)
return _user_cache[user_id]
看起来没问题对吧？但我们的场景是用户量很大，每个用户第一次访问就缓存了，之后永远不会清理。随着用户访问越来越多，缓存就越积越大。
第三步：修复
最简单的方案，换成LRU缓存：
from functools import lru_cache@lru_cache(maxsize=10000)
def get_user(user_id):
return fetch_user_from_db(user_id)
加了maxsize后，缓存超过10000条就自动淘汰最久没访问的。内存占用稳定在300MB左右，问题解决。
反思
其实这个坑很低级，但当时写代码的时候确实没想到用户量会到这个级别。几个教训：
- 全局缓存一定要有淘汰策略，不管你用
lru_cache、cachetools.TTLCache还是Redis，总之不能只进不出 - 上线前做一下内存压测，模拟一段时间的持续请求，看内存是否持续增长
tracemalloc是排查Python内存问题的利器，比凭直觉猜靠谱多了
顺便说一句，如果缓存的数据来自API调用，还要考虑缓存过期的问题。之前我有个项目调大模型API，结果缓存了过期的响应，debug了好久才反应过来。国内用这些API有时候响应慢或者不稳定，我后来换了个中转站，响应速度好了不少，缓存命中率也提上去了。
就这些，希望对你有帮助。Python
火山引擎是字节跳动旗下企业级云与AI服务平台。聚焦大模型核心能力，依托字节自研豆包多模态大模型，凭借火山方舟一站式平台，提供模型精调、推理部署、智能应用搭建等全链路服务，结合高性能AI算力，助力各行业快速落地大模型数字化与智能化应用。
AirBuddy 3 是面向 macOS 的蓝牙外设增强工具，可集中查看 AirPods、Beats 与苹果设备电量，提供快速连接、播放控制、电量提醒、桌面小组件和多台 Mac 外设接力等功能。
AirServer macOS版可把 Mac 转换为无线投屏接收端，通过 AirPlay 或 Google Cast 接收手机、平板和电脑画面，并支持多设备同时连接、高清镜像及会话录制，适合家庭娱乐、课堂教学、会议演示和应用展示。
Autodesk Maya 是面向影视、电视、动画和游戏行业的专业三维制作软件，集多边形与 NURBS 建模、角色绑定、关键帧和动作捕捉动画、Bifrost 特效模拟、材质开发及 Arnold 渲染于一体，
AirServer Windows版可把电脑变成AirPlay、Google Cast和Miracast无线投屏接收端，适合会议演示、课堂教学及家庭大屏分享。发送设备通常无需另装客户端，并可同时接收和智能排列多个镜像会话。