拷贝语义+超大syscall缓冲区+内存受限，会导致Linux崩溃吗？

核心结论 #

这个场景下write()系统调用无法正常完成，会触发OOM Killer终止目标进程，但几乎不会导致系统崩溃。

详细分析 #

1. 内存需求的矛盾点

Linux的write()系统调用遵循拷贝语义：内核会将用户态缓冲区的数据完整复制到内核页缓存后，才会开始向存储设备写入。这意味着：

• 线程1发起write()时，内核需要为页缓存分配1.5GiB物理内存；
• 线程2随即修改整个用户态缓冲区，由于用户态页本身是可写的，修改操作不会触发Copy-On-Write（COW）——内核已经读取过用户页数据，用户线程修改自己的页会直接占用独立的物理内存区域，因此此时系统需要同时容纳用户态1.5GiB缓冲区和内核1.5GiB页缓存，总需求3GiB，远超系统仅有的2GiB物理内存。

2. 内存耗尽后的处理流程

当内核无法分配足够的物理内存时，会按以下步骤处理：

• 直接内存回收：内核尝试释放可回收内存（如干净页缓存、slab分配器中的闲置对象）。但由于存储设备速度极慢，脏页无法快速写入磁盘释放，回收操作会失败。
• OOM Killer激活：回收失败后，内核启动OOM Killer，根据进程的oom_score（内存占用、是否为核心进程等指标）选择优先级最高的进程终止。这个双线程用户态进程是当前内存消耗最大的对象，会被优先选中终止。

3. 最终结果与系统稳定性

• write()调用的结果：进程被终止后，write()会直接返回错误（如-EINTR）或随进程退出而中断，无法完成数据写入。
• 系统状态：OOM Killer成功终止用户进程后，释放的内存会恢复系统正常运行，不会崩溃。只有在极端情况（如无合适的用户进程可终止，或内存耗尽到OOM Killer自身无法运行）下，才会触发OOM Panic导致系统崩溃，但这种情况在该场景下概率极低。
• 无死锁风险：内核内存分配路径内置死锁避免机制，不会因内存耗尽导致系统挂起死锁。

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