Linux内存管理实战：free命令输出到底怎么看？

在Linux运维这行待久了，你会慢慢发现一个反直觉的规律：基础工具的名字越简单，想真正讲透就越难。free 就是最典型的一个。你问新人“查内存用什么”，十有八九会回答“free -h”，可你要是多追问一句：“available 那一列是怎么算出来的？”“buff/cache 到底是缓存还是缓冲？”“为什么 used 不高，swap 却一直在涨？”——能接住的人立刻少一多半。RHCA 的性能调优系列课程里，内存篇的第一课并不是教你怎么装监控软件，而是先逼你把 free 的输出吃得透透的。这篇文章我就拿 free 当抓手，把它背后牵扯的内存管理机制、企业环境里的判断标准、常见的误读坑点一次讲清楚。不管你是刚入行的运维、备考 RHCA+ 的工程师，还是想搞懂 Linux 内存机制的开发者，这篇应该都能给你一点参考价值。

1. 先搞清楚：free 命令在 RHCA+ 体系里到底是什么分量

1.1 从考试和实战两个角度看“最简单的命令”

先说考试视角。RHCA 系列中与性能调优直接相关的课程，开篇会有很长一段时间花在“看懂 baseline”上。而 baseline 里第一个要会看的，就是 free 的输出。不是因为命令本身难，而是因为 free 展示的每个数字背后都连着内核的内存管理逻辑——kswapd 回收机制、页缓存（page cache）、slab 分配器、swap 换页策略、OOM 判定的临界条件。这些东西哪怕你只理解七成，再去看 vmstat、sar、top 的输出都会觉得突然通透了不少。

再说实战视角。我接手过不少“内存告警”工单，最后定位下来，真正需要动服务器的只有不到一半，剩下的一半是监控告警阈值设得太粗暴，比如只看 used 占比、不看 available，结果数据库服务器明明还剩 20G 可用内存，告警系统却因为“used 超过 80%”疯狂报警。这种场景我非常熟悉，因为觉得 free 太简单而不愿意深究的人，最容易在误判的坑里打转。

1.2 free 与内核内存管理模型的关系

free 命令本身做的事情非常简单：读取 /proc/meminfo，然后把数据整理成人类友好的格式打印出来。它本身几乎不消耗什么计算资源，也没有“采样”概念，你执行多少次，它读到的就是那一刻内核统计的内存状态。可以说，free 只是个“显示器”，真正的“计算逻辑”全部在内核里。

那内核里的核心模型是怎样的？可以这样理解：物理内存被内核看成一个大池子，一部分分配给内核自身使用，一部分按需分配给用户态进程，还有很大一部分用来做“缓存”，消化磁盘 I/O 和文件读写带来的压力。free 输出里的 buff/cache 就是最后这一类。很多新手看到 used 很高就慌，其实一个长时间运行的 Linux 服务器，buff/cache 占了一半以上是非常正常的，因为内核的设计哲学是“空闲内存不如拿来做缓存”，白白闲置才是最浪费的用法。

1.3 free 的边界：它看不到哪些东西

这里要泼一盆冷水：free 虽然叫“查看内存资源”，但它给的是系统全局视角，并不是每个进程的视角。如果你想知道某个 Java 进程为什么占了那么多内存，靠 free 是远远不够的，你得结合 ps、pmap、smaps 甚至 jstat 去看。

打个比方，free 告诉你的是“整栋楼的用水总量”，但到底是哪家水管漏水，它完全看不出来。再极端一点，你在 C 语言里定义一个栈变量、一个全局静态变量，或者 malloc 一段堆内存，它们的物理落点完全不同——栈通常在进程地址空间的高地址向低地址增长，全局静态变量和数据段沉淀在一起，堆由 glibc/内核的 brk 和 mmap 管理——这些细节 free 一概不会告诉你，它只给你一个聚合之后的系统数字。理解这一层，你就能明白 free 的定位：它是宏观判断工具，不是微观定位工具。

2. 输出里的每一列到底在说什么

2.1 第一行 Mem：六个字段逐个拆

现在看一个最典型的 free -h 输出：

第一行 Mem 有六个字段，含义如下：

• total：物理内存总量，等于 free + used + buff/cache 的和（严格来说还包含 shared）。
• used：已经被“用到”的内存，这里要加个引号，因为它的统计口径并不是简单等于