python进程被系统直接killed而非抛出memoryerror，是因为oom killer在物理内存耗尽时强制发送sigkill终止高rss进程，该信号不可捕获；可通过dmesg -t | grep -i "killed process"确认，需用ulimit -v或cgroups从系统层限制内存，避免pandas读取、numpy转换、多进程等叠加操作引发oom。
为什么Python进程会被系统直接Killed而不是抛出MemoryError？
Linux内核的OOM Killer会在物理内存严重不足时，强制终止占用内存最多的用户进程，而不是让Python触发MemoryError。这是因为Python的内存分配（如malloc）失败时，C层会返回NULL，而CPython部分路径未做充分检查，最终由内核接管并发送SIGKILL——这个信号无法被捕获或忽略，所以你只会看到终端输出Killed，没有任何堆栈或异常信息。
如何快速确认是OOM Killer干的？
执行以下命令查看最近被杀的进程记录：
dmesg -T | grep -i "killed process"
如果输出类似：[Tue May 14 10:23:41 2024] Out of memory: Kill process 12345 (python) score 892 or sacrifice child，就坐实了OOM Killer介入。注意：不要只查journalctl或应用日志，它不会记录这个事件。
常见误判点：
- 误以为是代码里
sys.exit()或os._exit()导致——但这些会产生退出码，不是Killed - 误查
/var/log/syslog而漏掉dmesg缓冲区（它不落盘，重启后丢失）
怎样限制Python进程的内存上限避免被Kill？
靠Python自身无法阻止OOM Killer，必须从系统层设限。推荐用ulimit或cgroup，优先选ulimit（简单、兼容性好）：
在启动前加限制（单位是KB）：
ulimit -v 2097152; python your_script.py
这表示虚拟内存上限2GB（-v含堆、栈、mmap等）。注意：
-
-v比-m（物理内存）更可靠，因为现代Python大量使用mmap（如numpy.memmap、mmap.mmap），-m不生效 - 值设太小会导致
malloc: Cannot allocate memory，需根据数据规模试探（例如处理1GB CSV，建议预留至少1.5倍虚拟内存） - 在Docker中要用
--memory而非ulimit，且需同时配--memory-swap=0禁用swap，否则OOM Killer仍可能触发
哪些Python操作最容易触发OOM Killer？
不是所有大对象都会立刻引爆OOM Killer，关键看是否引发连续、不可控的内存增长：
-
pandas.read_csv(..., dtype=object)：字符串列默认不推断类型，每行都存为独立Python对象，内存膨胀可达原始文件5–10倍 -
list(range(10**9))：Python 3中range是惰性的，但转成list就全加载到内存 -
numpy.array(large_list, dtype=np.float64)：隐式拷贝+类型转换，尤其当large_list本身已占内存时，峰值内存≈2×原始大小 -
concurrent.futures.ProcessPoolExecutor未设max_workers：每个worker都复制父进程内存镜像，N个worker可能吃掉N×内存
真正危险的是“叠加型”操作——比如先read_csv加载，再groupby().apply(...)触发多进程，再to_parquet缓存中间结果。这种链路几乎必然触发OOM Killer，而不是报错。
最常被忽略的一点：即使你用del删了变量，CPython的引用计数释放是即时的，但底层内存未必立即归还给系统（尤其是malloc的arena机制），所以ps aux看到的RES值不会立刻下降——别以为删了就安全了。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
