Python无法捕获OOM错误，因操作系统在内存耗尽时直接发送SIGKILL信号终止进程，try/except和finally等机制均失效；确认需查dmesg日志或容器退出码137。
Python中根本捕获不到OOM错误
操作系统在内存耗尽时会直接杀死进程，Python的try/except完全无法拦截——这不是Python异常，而是OS级别的信号（Linux下通常是SIGKILL）。你看到的Killed输出、空日志、进程静默退出，基本就是OOM的典型表现。
- 所有基于
MemoryError的捕获逻辑都无效：它只在Python主动申请内存失败时抛出（比如list(range(10**12))），而真实OOM发生在系统拒绝分配页帧时 -
atexit.register()、finally块、析构函数（__del__）在SIGKILL下全部不执行 - 容器环境（如Docker）中更隐蔽：
docker stats显示内存使用逼近limit，但应用日志里找不到任何报错
如何确认是OOM而非其他崩溃
靠日志和系统痕迹交叉验证，而不是等Python报错。
- 检查系统日志：
dmesg -T | grep -i "killed process"，出现类似[Tue Apr 2 10:23:45 2024] Out of memory: Kill process 12345 (python) score 894 or sacrifice child就实锤了 - Docker用户看容器退出码：
docker inspect <container_id> | grep -i "status\|oom"</container_id>，"Status": "exited", "ExitCode": 137是SIGKILL的标准退出码 - 用
psutil做轻量级监控：在主循环里定期记录psutil.Process().memory_info().rss，配合时间戳写入文件；OOM前通常能看到内存曲线陡升
预防性内存监控与主动降级
既然不能捕获，就转为“提前感知+快速响应”。
- 用
resource.getrlimit(resource.RLIMIT_AS)读取当前进程虚拟内存限制（注意：Linux上该值常为-1即无限制，需结合cgroup或容器limit判断） - 关键路径插入内存水位检查：比如处理大文件前，先调用
psutil.virtual_memory().percent > 90，超阈值则跳过非核心逻辑或返回简化结果 - 对生成器/流式处理强制分块：
pandas.read_csv(..., chunksize=1000)比一次性read_csv安全；自定义迭代器中每处理N条就gc.collect() - 避免隐式内存放大：如
df.groupby(...).apply(lambda x: x.copy())可能复制整个DataFrame；改用transform或向量化操作
调试阶段快速定位内存热点
线上不能捕获，但开发/压测阶段必须精准定位谁在吃内存。
立即学习“Python免费学习笔记（深入）”；
- 用
tracemalloc（标准库）：启动时加tracemalloc.start(25)，OOM后立即dump：snapshot = tracemalloc.take_snapshot()，再用snapshot.statistics('lineno')查最占内存的代码行 - 警惕
__slots__缺失：未定义__slots__的类实例会带一个__dict__，百万对象时额外吃几百MB - 第三方库陷阱：如
lxml解析XML后不调用root.clear()，DOM树驻留内存；numpy数组切片默认是view，但copy=True误写成copy=False也可能导致意外引用
真正难的不是写个try，而是理解内存生命周期不在Python解释器手里——它横跨内核、cgroup、malloc分配器、Python GC多层。监控点必须打在OS边界上，而不是等MemoryError。
