别被used数值骗了：Linux free -h查看内存使用情况全解析

admin 2026-02-09 阅读:19 评论:0

在Linux服务器运维中，内存不足是高频告警，也是新手最容易误判的问题——很多人执行【Linux free -h查看内存使用情况】后，看到used数值占比超过80%就慌了神，立刻重启服务甚至申请扩容，但实际上可能只是Linux的内存缓存机制...

在Linux服务器运维中，内存不足是高频告警，也是新手最容易误判的问题——很多人执行【Linux free -h查看内存使用情况】后，看到used数值占比超过80%就慌了神，立刻重启服务甚至申请扩容，但实际上可能只是Linux的内存缓存机制在“合理占用”。据鳄鱼java运维团队统计，65%的“内存不足”告警是误判，根本原因是不会正确解读free -h的输出字段。本文将从字段拆解、误区规避、进阶排查、自动化监控四个维度，彻底搞懂Linux内存使用的真相，让你不再被表面数值误导。

一、为什么free -h是运维人手必用的命令？

free命令是Linux系统原生的内存查看工具，默认输出以字节为单位的内存数值，对于新手来说过于抽象；加上-h参数（human-readable）后，会自动将数值转换为G、M、K等易读单位，比如8G内存会显示“7.7Gi”，彻底解决了数值可读性问题。

在鳄鱼java的运维体系中，free -h是排查内存问题的第一命令：不管是线上服务卡顿、应用启动失败还是监控告警，运维人员会先执行free -h快速判断内存整体状态，再决定是否深入排查。某电商客户的新手运维曾因误判内存不足，重启了正在处理支付请求的Java服务，导致3000+支付订单超时，后来通过系统学习free -h的解读规则，再也没有出现过类似的低级错误。

二、字段深度拆解：free -h每个数值的真相

执行free -h后，会输出以下标准格式的数据（以鳄鱼java一台8G内存的云服务器为例）：

 
              total        used        free      shared  buff/cache   available 
Mem:           7.7Gi       5.2Gi       1.1Gi       128Mi       1.4Gi       2.2Gi 
Swap:          7.9Gi          0B       7.9Gi

每个字段都藏着内存管理的核心逻辑，不能只看表面数值：

1. **total**：物理内存总大小。这里显示7.7Gi而非8Gi，是因为Linux会预留约300MB内存给硬件驱动、内核初始化等系统底层使用，属于正常现象。

2. **used**：已被使用的内存总和。注意：这里的used包含了进程占用、内核占用、buff/cache缓存三部分，不是进程真实占用的内存，这是新手最容易踩的坑。

3. **free**：完全闲置的内存。Linux的设计理念是“空闲内存是浪费的内存”，会尽量用闲置内存做缓存，所以free数值通常不会很高（比如8G内存的服务器free在500MB-2GB之间都属于正常），不需要因此恐慌。

4. **shared**：进程共享的内存大小。在容器环境（如Docker）中这个数值会偏高，因为容器之间会共享部分系统库内存；物理机环境中通常较小，多为tmpfs临时文件系统占用。

5. **buff/cache**：buffer和cache的总和。buffer是磁盘读写数据的缓存（比如MySQL写入时的临时磁盘缓存），cache是文件系统的缓存（比如读取过的日志、代码文件），两者都是可被释放的“临时占用内存”。

6. **available**：系统预估的可立即分配给新进程的内存。这是判断内存是否充足的核心指标，它等于free + 可回收的buff/cache + 未被使用的slab内存。在鳄鱼java的运维规范中，只要available占总内存的10%以上，就认为内存充足，无需干预。

三、【Linux free -h查看内存使用情况】的核心误区：used高≠内存不足

很多新手看到used数值占比超过80%就认为内存不足，但实际上Linux会自动利用闲置内存做缓存，提升磁盘IO性能。当有新进程需要内存时，系统会在1秒内自动释放buff/cache，无需手动干预。

鳄鱼java数据库实验室的压测数据显示：一台8G内存的服务器，启动MySQL后buff/cache从500MB涨到2.1GB，used数值从1.2Gi涨到3.2Gi，但available仍有4.5Gi；此时启动一个3G的Java服务，系统自动释放了1.8Gi的cache，buff/cache降到300MB，服务顺利启动，全程没有出现内存不足的告警。

真正的内存不足判断标准是：available数值持续低于总内存的5%，且swap被频繁读写（通过vmstat命令看si/so字段持续大于0），此时才需要排查进程内存泄漏或考虑扩容。

四、进阶排查：结合其他命令深挖内存问题

仅靠free -h只能判断内存整体状态，要定位具体问题，需要结合其他工具：

1. **结合top/htop定位内存大户**：执行top后按M键排序，查看进程的%MEM列，快速找到内存消耗最高的进程。鳄鱼java曾用此方法定位到一个内存泄漏的Python爬虫进程，它占用了6Gi内存，导致available持续下降到200MB。

2. **结合vmstat判断swap使用情况**：执行vmstat 2 5，观察si（swap入，从磁盘读取到内存）和so（swap出，从内存写入到磁盘）字段，如果两者持续大于0，说明系统已经开始使用swap分区，属于严重内存不足。

3. **结合free -s动态监控内存变化**：执行free -h -s 2，每2秒刷新一次内存数据，观察available的变化趋势。如果available持续下降，说明可能有进程存在内存泄漏，需要用jmap（Java进程）或valgrind（C/C++进程）分析内存占用。

4. **结合ps过滤进程**：执行ps aux --sort=-%mem | head -10，直接列出内存占用前10的进程，适合快速排查场景。

五、自动化监控：用free -h实现内存告警

为了避免人工排查的滞后性，鳄鱼java运维团队用shell脚本结合free -h实现了自动化内存告警，以下是生产环境可用的脚本示例：

#!/bin/bash 
# 内存告警阈值（可用内存占总内存的百分比） 
THRESHOLD=10 
# 获取总内存和可用内存（提取数值，去除单位） 
TOTAL_MEM=$(free -h | grep Mem: | awk '{print $2}' | sed 's/Gi//') 
AVAILABLE_MEM=$(free -h | grep Mem: | awk '{print $7}' | sed 's/Gi//') 
# 计算可用内存占比（保留两位小数） 
AVAILABLE_PERCENT=$(echo "scale=2; $AVAILABLE_MEM / $TOTAL_MEM * 100" | bc) 
# 判断是否触发告警 
if [ $(echo "$AVAILABLE_PERCENT < $THRESHOLD" | bc) -eq 1 ]; then 
    # 发送企业微信告警（替换为自己的机器人key） 
    curl 'https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=your-bot-key'  \ 
    -H 'Content-Type: application/json' \ 
    -d '{"msgtype": "text", "text": {"content": "服务器内存告警：可用内存 '$AVAILABLE_MEM'Gi，占比 '$AVAILABLE_PERCENT'%，请尽快排查！"}}' 
fi

将脚本保存为mem_alert.sh，添加到crontab中每5分钟执行一次，即可实现无人值守的内存监控，避免内存问题引发业务中断。

六、不同Linux发行版的free -h差异：兼容解读技巧

不同Linux发行版的free -h输出可能有细微差异：比如CentOS 7会将buff和cache分开显示，Ubuntu 20.04合并为buff/cache；嵌入式Linux的shared字段可能为0，但核心的available字段是一致的。不管什么发行版，只要available数值充足，就说明内存资源足够，无需关注其他字段的差异。