应关注 free -h 输出中的 available 值而非 free 列，因为 available 才是内核估算的、无需触发 OOM killer 即可立即分配的内存，包含可回收的 buff/cache，真实反映可用内存。
别看 free 输出里的 free 列——它不是你真正能用的空闲内存，多数时候这个值严重误导人。
为什么 free 命令的 free 列不准
Linux 内核会把大量“暂时不用”的内存划给 buffers 和 cache（比如文件读写缓存、目录索引等），这部分内存随时可被回收，但 free 列只统计完全没被分配的页面，不包含这些可回收缓存。所以你会看到：free 列只有几百 MB，而 available 列有几 GB——后者才是你启动新进程时实际能拿到的内存。
-
free：纯空闲页，几乎从不接近 0，不代表真实可用性 -
available：内核估算的、无需触发 OOM killer 就能立即分配的内存，含可回收缓存 -
buff/cache高 ≠ 内存紧张，反而是系统在高效利用资源
free -h 中必须盯住的字段是 available
运行 free -h 后，直接看第一行 Mem: 对应的 available 值：
total used free shared buff/cache available Mem: 15G 6.2G 844Mi 1.1G 7.9G 7.4G Swap: 2.0G 256Mi 1.8G
上例中，available: 7.4G 才是你此刻能安全分配给新程序的内存。如果这个值持续低于总内存的 10%（比如 15G 总内存下
- 加
-h是必须的，避免单位混淆（KB/MB/GB） - 不要用
-m或-g硬指定单位，-h自动适配更可靠 - 容器环境或低内存设备中，
available可能被 cgroup 限制，需结合cat /sys/fs/cgroup/memory/memory.usage_in_bytes核对
当 available 值异常低时，下一步查什么
如果 available 持续偏低，说明物理内存确实吃紧，但原因未必是某个大进程——可能是缓存无法释放、内存泄漏或内核参数限制。
- 先用
ps aux --sort=-%mem | head -5快速定位内存大户 - 检查是否启用了
vm.swappiness=0：这会让内核拒绝回收缓存，导致available虚低（尤其在数据库场景） - 运行
cat /proc/meminfo | grep -E "^(MemAvailable|MemFree|Cached|SReclaimable)"，确认MemAvailable与free输出一致，排除工具版本差异 -
swapon --show=USED查 Swap 是否已启用并占用——一旦 SwapUsed > 0，基本可判定物理内存已不足
真正决定系统是否“快撑不住”的，从来不是 free 列那个冷冰冰的数字，而是内核动态维护的 available 值——它背后是页回收机制、LRU 链表、cgroup 限额等一系列实时决策。盯着它，比反复刷新 top 更早发现问题。
