应重点关注 free -m 输出中 mem 行的 available 列与 swap 行的 free 列，用 watch -n 2 -d free -m 实时监控，并结合 available/total 计算真实空闲比，辅以日志采样和 jstat 验证 jvm 内存状态。
在 Java 应用 Linux 线上部署中，用 free -m 实时观察内存与 Swap 空闲比例，核心是理解输出字段含义，并通过简单脚本实现动态监控，而非依赖单次快照。
看懂 free -m 输出的关键列
free -m 以 MB 为单位显示内存使用情况。重点关注以下三行：
-
Mem 行：物理内存。其中
free是当前完全未被使用的内存（不含 cache/buffer），available才是真正可被新进程立即使用的内存（推荐优先看这一列） -
Swap 行：交换分区。
free列表示尚未使用的 Swap 容量 -
注意：空闲比 ≠
free / total，尤其对物理内存，因 Linux 会积极利用空闲内存做缓存；available / total更反映实际可用余量
用 watch 实现“实时”刷新监控
无需写 Java 程序调用系统命令，直接在终端用 watch 命令周期执行 free -m：
Java JDK 25
下载
Java JDK 25 来自 OpenJDK 官方归档，版本为 JDK 25，本条下载地址已指向官方 Windows x64 zip 安装包直链，适合调试旧项目或兼容旧版 Java 运行环境。
- 执行
watch -n 2 free -m：每 2 秒刷新一次，带清晰标题和高亮变化 - 加
-d参数（如watch -n 2 -d free -m）可高亮显示变动的数值，便于快速识别内存波动 - 若只关心空闲比，可用
awk提取并计算百分比：watch -n 3 'free -m | awk "NR==2 {printf "Mem Free%%: %.1f%%\n", $7/$2*100} NR==4 {printf "Swap Free%%: %.1f%%\n", $4/$2*100}"'
结合 Java 应用场景判断是否异常
单纯数值不说明问题，需结合 JVM 和业务行为分析：
- 物理内存
available持续低于 5% 或频繁触发 Swap 使用（Swap used > 0），可能引发 GC 延迟升高或进程被 OOM Killer 杀死 - Swap 使用量缓慢增长但未达上限，可能是 JVM 堆外内存泄漏（如 DirectByteBuffer、JNI、Netty 的 native memory）或系统级服务占用
- 若
free很低但available充足，属正常现象，不必干预
生产环境建议的轻量监控方式
避免长期挂 watch 占终端，可用后台日志+定时采样：
- 每 10 秒记录一次关键指标到日志：
while true; do free -m | awk 'NR==2{mem=($7/$2)*100} NR==4{swap=($4/$2)*100} END{printf "%s Mem:%.1f%% Swap:%.1f%% ", strftime("%H:%M:%S"), mem, swap}' >> /var/log/memory.log; sleep 10; done & - 配合
grep快速查看近期趋势：tail -100 /var/log/memory.log | sort -k2nr | head -5查最高内存占用时段 - Java 进程自身内存使用应同时用
jstat -gc <pid></pid>对比验证，避免仅依赖系统视图
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
