进程挂起通常因OOM Killer杀掉或卡在D状态等待内存分配，可通过ps查STATE为D、wchan为mm_page_alloc等函数、/proc/[PID]/stack含try_to_free_pages确认；free有余量但分配失败主因是内存碎片、zone不平衡或min_free_kbytes过高导致无法满足连续页请求。
进程因内存分配失败而挂起，通常不是“静默挂起”，而是已被内核干预——要么被 OOM Killer 杀掉，要么卡在系统调用（如 brk、mmap）上等待内存，表现为 D 状态（uninterruptible sleep），此时 ps 显示 STAT 列为 D，且无法被 kill -9 终止。
怎么确认进程卡在内存分配上？
先看进程状态是否为不可中断的 D：
- 运行
ps -eo pid,comm,state,wchan:20,vsz,rss,time --sort=-rss | head -10，重点关注STATE列是D还是R/S - 若为
D，再查WCHAN（等待的内核函数）：常见值如mm_page_alloc、__alloc_pages_slowpath、do_mmap，直接指向内存分配阻塞 - 配合
cat /proc/[PID]/stack查看内核栈（需 root）：如果末尾出现wait_event_killable+try_to_free_pages或oom_killer_disable，基本可断定正卡在内存回收或 OOM 处理路径上
为什么 free 显示还有内存却仍分配失败？
这不是“没内存”，而是“没有满足条件的内存”：
-
available值低 ≠ 物理页全满，但可能因内存碎片（尤其低阶页）、zone 不平衡（如 DMA zone 耗尽）、或min_free_kbytes保护水位过高，导致无法分配连续页（比如mmap请求大块内存、或内核模块申请kmalloc(1MB)） -
slabinfo中某 cache（如size-4096）num_slabs高但sharedavail接近 0，说明 SLAB 缓存已碎片化，无法满足新分配 - 检查
cat /proc/buddyinfo：若Order 9（2MB）或Order 10（4MB）对应数字为 0，而程序恰好需要这么大的连续页，就会失败并挂起
如何快速验证是不是 OOM Killer 干预了？
别只看 dmesg 最后几行，要查完整 OOM 上下文：
- 执行
dmesg -T | grep -A 20 -B 5 "Out of memory"，注意时间戳是否与进程挂起时间吻合 - 关键线索不止是
Kill process，更要关注前几行：Mem-Info:后面的active_anon、inactive_file、unevictable比例，以及pagesets是否显示lowmem_reserve[]触发保护 - 若日志里有
Task in /system.slice has been killed，说明 cgroups 内存限制触发了本地 OOM（memory.oom_control），而非全局 OOM Killer
挂起后还能抢救吗？
绝大多数情况下不能“唤醒”，只能释放资源让内核继续：
- 若进程处于
D状态且WCHAN是内存分配相关函数，唯一可靠方式是释放内存压力源：杀掉其他高 RSS 进程、清缓存（echo 3 > /proc/sys/vm/drop_caches）、关闭 swap（swapoff -a可能反而加重压力，慎用） - 不要尝试
sysctl vm.panic_on_oom=1或重启内核参数——这只会让问题更不可控 - 真正该做的，是在挂起发生前就监控
/proc/[PID]/status中的MMU相关字段（如Threads、voluntary_ctxt_switches异常飙升），或用bpftrace抓kmalloc/vm_brk失败事件
挂起本身是内核的防御性冻结，不是 bug；但反复出现，说明应用内存模式和系统配置严重不匹配——比如一个 C++ 程序频繁 mmap(MAP_HUGETLB) 却没预留 hugepage，或 Java 应用 -XX:+UseLargePages 但 /proc/sys/vm/nr_hugepages 为 0。
