Java进程被kill的直接原因是物理内存耗尽触发OOM Killer，Swap仅是缓冲层；Swap高使用（如超70%）表明内存已严重不足，此时si/so升高、MemAvailable低于500MB即属高危，需立即启用Swap并调小-Xmx。
Java进程被操作系统直接kill，和Swap分区“满”没有直接因果关系——Swap本身不会“满”到触发kill，真正起作用的是物理内存耗尽后触发的OOM Killer机制。Swap只是延缓或掩盖问题的缓冲层，不是根源。
Swap高 ≠ Swap满，但Swap使用过量是危险信号
Swap被大量使用（比如占用超过70%），往往说明物理内存已严重不足，JVM堆内存或系统其他进程正在频繁将不活跃页换出到磁盘。此时虽然进程还在运行，但性能已急剧恶化：
- GC时需把大量Swap页换回物理内存，导致STW时间暴涨（可能达秒级甚至分钟级）
- 系统整体响应迟滞，I/O等待升高，top中%wa（iowait）明显偏高
- 并非Swap“满了”才出事，而是Swap活跃使用 + 物理内存见底 → 触发OOM Killer
根本原因：物理内存不足 + 无可用Swap空间（或Swap被禁用）
从多个真实案例看（如8G内存机器配6G堆、禁用Swap），进程被kill的关键路径是：
- JVM申请堆外内存（DirectBuffer）、线程栈、CodeCache、Native Libraries等，叠加Java堆，总RSS远超物理内存
- 系统未配置Swap，或Swap空间为0（
swapon --show为空），无法提供额外虚拟内存缓冲 - 内核检测到
MemAvailable ≤ 0且无法回收足够内存，启动OOM Killer选择得分最高的进程（通常是RSS最大的Java进程） -
dmesg | grep "oom-killer"日志里会明确显示anon-rss: XXXX kB和free: YYYY kB，两者相加接近总物理内存
如何验证是否由Swap相关内存压力引发
别只看Swap使用率，重点查三组指标是否同时告急：
立即学习“Java免费学习笔记（深入）”；
-
物理内存真实水位：
grep -i "memavailable\|memfree" /proc/meminfo，MemAvailable持续低于500MB即高危 -
Java进程实际驻留内存：
pmap -x <pid> | tail -1看RSS列（单位KB），对比物理内存总量 -
Swap活动强度：
vmstat 1 5观察si（swap-in）和so（swap-out）是否持续>100（KB/s），>500即严重
有效应对策略：治标+治本结合
单纯加Swap能防kill，但不能解决性能恶化；必须同步降低内存压力：
-
立即生效：启用合理大小Swap（建议=物理内存，如8G内存配8G Swap），命令：
sudo fallocate -l 8G /swapfile && sudo mkswap /swapfile && sudo swapon /swapfile -
降低JVM内存 footprint：调小
-Xmx（如从6G→4G），关闭不必要的Native内存使用（如Netty的-Dio.netty.noPreferDirect=true） -
限制非堆开销：设置
-XX:MaxDirectMemorySize（默认等于-Xmx），防止NIO DirectBuffer失控 -
排查内存泄漏点：用
jcmd <pid> VM.native_memory summary确认是否Native内存持续增长
