真正能马上分给新进程的是 available 列，它由内核估算得出，已扣除不可回收部分并计入可回收的 page cache 和 buffers；free 列仅表示完全未被占用的裸内存，不能代表可用余量。
别看 free 输出里的 free 列
很多人一看到 free 命令输出里 free 那一列数值大，就以为“内存还很宽裕”，结果跑个新服务直接 OOM。这个 free 值只代表完全没被任何用途占用的裸内存，不包括可快速回收的缓存（buff/cache），实际根本不能当“可用余量”用。
真正能马上分给新进程的，是 available 列 —— 它由内核估算得出，已扣除了不可回收部分，并计入了可回收的 page cache 和 buffers。
-
free -h是最简命令，直接看Mem行的available值（单位自动适配） - 如果系统较老（kernel available 列可能缺失，此时需用
free -k+ 手动计算：MemAvailable = MemFree + Buffers + Cached - Shmem（但误差较大，仅作粗略参考） - 注意：该值是估算值，不是实时快照；它反映的是“当前可分配”的保守估计，不是“绝对剩余”
cat /proc/meminfo 里的 MemAvailable 更权威
/proc/meminfo 是 free 命令的数据源，其中 MemAvailable 字段和 free -h 的 available 列完全一致，但更少受终端格式化干扰，适合脚本或自动化判断。
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 执行
cat /proc/meminfo | grep MemAvailable，输出形如：MemAvailable: 7821252 kB - 这个值比
MemFree可靠得多；MemFree极低不代表内存紧张，MemAvailable持续低于总内存的 10% 才真要警惕 - 某些定制内核或容器环境（如 cgroups v1 限制严格时），
MemAvailable可能被低估，需结合Memory limit和usage综合判断
Swap 使用量是内存余量不足的硬信号
只要 Swap 行的 used 大于 0，就说明物理内存已经不够用了，内核开始把不活跃页换出到磁盘 —— 这时候 available 即使还有几百 MB，也已是强弩之末。
- 运行
free -h，重点扫一眼Swap行的第二列（used）是否非零 - 若
used持续增长，同时si/so（swap-in/swap-out）在vmstat 1 5中频繁非零，说明内存正在被反复挤压，响应延迟会明显升高 - 注意：有些系统默认禁用 Swap（尤其云服务器），此时
Swap行全为 0 不代表内存充裕，得盯紧MemAvailable是否持续走低
单进程视角下，“空闲余量”其实是动态竞争结果
系统整体 available 高，不代表某个进程能顺利 malloc 出大块内存 —— 内存碎片、cgroup 限额、NUMA 节点绑定都可能让“有余量却分配失败”。
- 用
ps aux --sort=-%mem | head -n 5查看谁在吃内存，%MEM高不一定危险，但RSS突增且持续不释放，往往预示泄漏 - 在容器中，
docker stats或cat /sys/fs/cgroup/memory/memory.usage_in_bytes才是该容器的真实占用，和宿主机free无关 - NUMA 架构服务器上，
numastat -p $(pgrep -f your_process)能看出进程是否跨节点分配内存，局部内存耗尽也会触发 OOM，哪怕全局available还剩很多
真正决定“还能不能起新服务”的，从来不是 free 或 cached，而是 MemAvailable 是否稳定、Swap used 是否为零、以及关键进程是否有足够连续物理页可分配 —— 这三者缺一不可。忽略任一环节，都可能在看似宽松的数字背后踩进内存陷阱。
