北京
新手看Linux内存，99% 都会被 free -h 的输出吓一跳。你打开终端，敲下 free -h，看到 Total 13.5 GiB，Free 却只有 271 MiB，换算下来才 2%。第一反应绝对是：“卧槽，内存要爆了！”但你再仔细看，Available 这一列赫然写着 7.10 GiB。系统非但没瘫，反而稳得像块砖。这个信息差，就是 /proc/meminfo 二十年来最大的坑。
要理解这个坑，你得先搞清内核对内存的态度。MemFree 不是你想象中的“还有多少内存可用”，而是内核正在“毫无作为”的内存——既没有给文件做缓存，也没有缓冲任何写操作，就是干躺着。在内核眼里，这种空闲内存简直是浪费，所以它会主动把剩余的物理内存用来存放页缓存（page cache），让磁盘上的文件块呆在内存里，读写时快得飞起。一旦有进程真的需要分配内存，内核会立刻把缓存中的可回收页吐出来，几乎零延迟。因此，一台健康运行的 Linux 机器，MemFree 的值天然就会趋向于零，它并不是危险信号，反而是内核充分利用了所有资源的标志。误以为 MemFree 高才安全，才是对 Linux 内存管理最大的误解。
正因为这种普遍误读，内核在 3.14 版本中专门引入了 MemAvailable 字段。MemAvailable 是一个估算值，它告诉你“现在不触发 swap 还能分配多少内存”。这个估算已经把大部分可回收的页缓存、slab 缓存都算了进去，比 MemFree 更贴近实际。于是就有了一个反直觉的公式：实际使用的内存 = MemTotal - MemAvailable，而不是像早期工具那样凑 MemTotal 减掉一堆字段去拼凑。经典的错误算法是 已用 = MemTotal - MemFree - Cached - Buffers，结果算出来 Linux 平白无故“吃”掉了好几 GB 内存，那个“Linux ate my RAM”的段子就是这么来的。
这里还有一个很容易掉进去的陷阱：试图让 Cached、Used、Free、Available 这几个数加回 Total。Cached 并不是独立于 Used 或 Available 之外的一块，它和 Available 是重叠的，也就是说，一笔缓存在回收后可以变成可用内存，但它同时也算在 Cached 中。如果你硬要画个韦恩图把四者拼成完整的 Total，怎么拼都不对。这是数据口径上的误区，和当年人们以为 Swap 加了 Available 就能把物理内存撑大一样荒谬。
看懂了这层关系，你再去对比各种系统监控工具的做法，就能理解为什么 btop 的算法这么简洁：used = MemTotal - MemAvailable。不做加减缓存，不做缓冲剔除，直接把估算工作交给内核自己。因为只有内核才知道哪部分缓存在真正需要时能立即回收，哪部分被钉住动不了。这种信任内核估算的策略，比任何用户态工具自己耍小聪明都可靠。原文作者在 Rust 中实现这个采集器时，也只储存 u64 的字节数，不做任何单位换算，把格式化交给 UI 层，再一次印证了“让专业的做专业的事”。
回到那句 free -h 的输出，当你看到 Free 271 MiB 时，不要急着去关掉无用的服务，也不要立刻动手扩内存。看一眼 Available，它才是内核为你预留的弹药。这个从 /proc/meminfo 里拆出来的教训，说明了一个朴素的运维道理：数据要看对字段，工具要用懂口径。否则，你很可能在帮内核数鬼影，然后白操了半天的心。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
