最直接有效的方式是运行 free -h 查看 Swap 使用量，关注 Swap 行的 used 值；再用 vmstat 1 5 观察 si/so 判断是否频繁换页；结合 top/htop 定位高 Swap 占用的 Java 进程，并通过 cat /proc/PID/status | grep VmSwap 获取其精确换出量。
OpenJDK 本身不提供直接查看系统 Swap 的能力——它运行在 JVM 上，而 Swap 是 Linux 内核管理的系统级资源。你要查的是**宿主机的 Swap 使用情况**，不是 JVM 进程专属的 Swap；但 OpenJDK 应用（比如 Java 服务）往往是 Swap 的主要触发者，所以得把「看系统 Swap」和「看 Java 进程是否被换出」结合起来。
free -h 看 Swap 总用量，但别只盯 used
这是最快速确认 Swap 是否被启用、用了多少的命令：
- 运行
free -h，找到Swap行的used值：只要大于0（如128M、2.1G），说明内核已开始将内存页换出到磁盘 -
used接近total（例如3.9G / 4.0G）是危险信号，但不等于立刻卡顿——得继续看活跃度 - 注意：
available是物理内存指标，和 Swap 无关；混淆它会导致误判内存余量
vmstat 1 5 看 si/so，判断 Java 是否真在“搬页”
Swap 用量高 ≠ Java 卡顿；真正伤性能的是持续的页面换入换出。OpenJDK 应用一旦大量触发 si（swap-in）或 so（swap-out），GC 延迟、HTTP 响应就会明显拉长：
Linux Security Scanner
下载
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
- 执行
vmstat 1 5，重点关注si和so两列，单位是 KB/s - 如果连续几秒
si或so> 100 KB/s（尤其 > 1 MB/s），基本可断定 JVM 正在频繁读写 Swap，物理内存已严重不足 - 此时
free -h的used可能早就上 G 了，但关键指标是si/so是否活跃
top 或 htop 查哪个 Java 进程在吃 Swap
光知道系统 Swap 高没用，得定位到具体是哪个 java 进程在贡献换出页：
- 运行
top，按f→ 选中SWAP字段（空格启用），再按Shift + P按 Swap 使用量降序排列 - 或者用
htop（需先sudo apt install htop），顶部状态栏直接显示 Swap 总用量，底部进程列表默认含SWAP列 - 找到
COMMAND为java的进程，观察其SWAP值（单位 KB）；再结合VIRT（虚拟内存）和RES（常驻内存）判断是否异常膨胀 - 进一步验证：取该进程 PID（比如
12345），运行cat /proc/12345/status | grep VmSwap，输出类似VmSwap: 824572 kB——这才是该 JVM 实际被换出的精确大小
swapon --show 和 /proc/swaps 确认 Swap 类型与优先级
OpenJDK 对 Swap 类型不敏感，但 Swap 配置不当会放大问题。比如 swap 文件权限错误、zram 未启用、多个设备 PRIO 设置反了，都可能导致本该走高速 zram 的页面全压到慢速磁盘上：
-
swapon --show输出里看TYPE：如果是file（如/swapfile），检查权限是否为0600（ls -l /swapfile），否则内核可能拒绝高效使用 - 若看到
zram0或zswap，说明启用了内存压缩型 Swap，此时free -h的used包含压缩后数据，但/proc/swaps可能不显示——别因此怀疑统计不准 - 多个设备时，
PRIO越大越优先；如果高优先级设备容量小又满载，低优先级的大分区反而闲置，导致 Swap 快速打满却无法分流
真正容易被忽略的是：Java 进程的 VmSwap 值可能长期不归零——哪怕应用已停，只要内核还没回收那些页，free -h 的 used 就不会掉。这不是泄露，也不是 bug，是 Linux 的保守策略；但如果你在压测后想清空 Swap，swapoff -a && swapon -a 是唯一可靠方式，而不是等它自己释放。
