std::bad_alloc与OOM killed的差异及重启后内存问题解析

1. OOM Killed与std::bad_alloc的触发条件差异 #

• std::bad_alloc触发场景：进程通过C++ new（或底层malloc类分配函数）申请内存时，操作系统内存分配器直接返回分配失败，此时标准库抛出std::bad_alloc异常。常见情况包括：进程内存使用达到自身资源限制（如ulimit设置的虚拟内存上限）；系统剩余内存+交换空间不足以满足当前进程的单次内存请求，但全局系统尚未触发强制回收机制；或系统关闭了内存过度提交（Linux下overcommit_memory设为2），内存分配时直接校验失败。
• OOM Killed触发场景：当系统物理内存+交换空间完全耗尽，操作系统OOM Killer（内存不足终止器）被激活。它会依据预设评分规则（如进程内存占用量、是否为系统关键进程、存活时长等）选择目标进程强制终止以释放内存。此时进程可能还没走到内存分配失败抛出异常的步骤——要么是后台内存申请直接触发系统全局OOM，要么是进程的内存请求压垮了系统剩余资源，触发强制回收。

2. OOM Killed后重启执行相同操作成功的原因 #

• 进程资源完全释放：被OOM Killer终止的进程会彻底释放其占用的所有内存、句柄等资源，系统因此腾出足够空间，重启后的进程自然能满足内存需求。
• 内存碎片得到缓解：长期运行的系统可能存在内存碎片，导致总剩余内存足够但无法分配出压缩所需的连续大块内存。进程被杀死后，原内存块被回收整理，重启后连续内存申请的成功率提升。
• 系统缓存与其他进程资源释放：OOM触发前后，系统可能自动清理页缓存等临时资源，同时其他进程也可能因内存压力主动释放部分资源，进一步腾出可用内存。
• OOM后的系统资源调整：部分系统在触发OOM后，会自动清理冗余缓存或调整内存分配策略，间接为后续进程提供了更充足的可用内存。

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