当前位置：首页 > 文章列表 > 文章 > linux > Linux内存查看方法：free与htop命令详解

Linux内存查看方法：free与htop命令详解

2026-05-16 15:32:36 0浏览收藏

想准确判断Linux系统是否真的内存不足，关键不是看free命令里那个总显得很低的“free”值，而是紧盯“available”字段——它才是内核估算出、可立即分配给新进程的真实可用内存，已智能扣除不可回收部分；而要精准揪出真正吃内存的进程，不能只依赖top或ps的RSS（会因共享库重复计算严重失真），必须用smem的PSS（按比例分摊后的净占用）才能避免误杀“背锅侠”、锁定真正的内存大户——available告诉你系统还有多少弹药，PSS告诉你谁在偷偷多领，二者结合，才能告别被缓存迷惑、误判内存泄漏或放任真实瓶颈的运维陷阱。

Linux怎么查看内存使用_Linux free和htop命令详解【资源】

怎么看清“真正可用”的内存，而不是被缓存骗了

Linux 会把空闲内存自动用作 buff/cache（缓冲区和页缓存），所以 free 输出里的 free 列数值低 ≠ 内存紧张——它只是“没被分配”，不是“不可用”。关键看 available 字段，它是内核估算的、能立刻给新进程用的内存（已扣减不可回收部分，含可释放缓存）。

free -h 是第一反应命令，输出中优先盯住 Mem 行的 available 值；如果它低于总内存的 10%，才真要警惕
别信 used = total - free 这个算式——used 包含了大量可回收缓存，直接减会高估压力
如果 available 很小但 buff/cache 很大，大概率是正常行为；除非同时出现 Swap used > 0 且持续上涨，那才是物理内存确实不够了

怎么快速揪出吃内存的进程，而不是在 top 里瞎翻

top 默认按 CPU 排序，按 M（大写）才能按内存排序，但它的 RES（常驻内存）字段容易受共享库干扰；htop 更直观，支持鼠标点列头排序、树状视图、颜色高亮，装一个省半小时。

终端执行 htop，按 F6 → 选 PERCENT_MEM → 回车，直接按内存占用百分比降序
若不能装 htop，用 ps aux --sort=-%mem | head -10 快速列出前 10 名，注意看 %MEM 和 RSS（单位 KB），避免只看 VIRT（虚拟内存，可能包含未分配空间）
Java/Python 进程 RSS 持续缓慢上涨？不一定是泄漏——检查 JVM 的 -Xmx 或 Python 的 ulimit -v 是否设得过大，导致内存“占着不用还涨”

/proc/meminfo 里哪些字段真有用，哪些只是干扰项

/proc/meminfo 是所有内存工具的数据源，但字段太多，90% 场景只需关注几个：

MemAvailable：和 free -h 的 available 一致，是判断是否缺内存的黄金指标
Active(file) / Inactive(file)：区分正在活跃使用的缓存 vs 可随时回收的缓存；如果 Inactive 占比高，说明缓存很“干净”，系统没压力
Slab 和 SReclaimable：前者是内核对象缓存总大小，后者是其中可回收的部分；若 Slab 高但 SReclaimable 低，可能是 dentry/inode 缓存堆积（尤其小文件多的 NFS 或容器场景）
别纠结 MemFree——它几乎永远很小，意义有限；也别一看到 SwapCached 就慌，它只是 swap 页被重新读入内存后缓存的副本，不等于正在换入换出

为什么 smem 比 ps 更准，什么情况下必须用它

ps 的 RSS 把共享库内存全算给每个进程，比如 20 个 Java 进程共用同一套 JVM 库，ps 会重复计算 20 遍；smem 用 PSS（Proportional Set Size）按比例分摊，更真实反映单个进程实际“净占用”。

安装后运行 smem -s pss -r | head -10，看谁真正拖垮内存；USS（独占内存）则适合定位纯泄漏——只增不减的进程 USS 持续涨，基本就是泄漏
对比 ps aux --sort=-rss | head -5 和 smem -s pss -r | head -5，常发现排名完全不一样：数据库连接池进程 RSS 高但 PSS 低，而某个 Python 脚本 RSS 中等但 PSS 突出——这才是真凶
smem 依赖 /proc/PID/smaps，某些容器或安全加固环境可能禁用该接口，此时会报错或缺失数据，得切回 ps + top 组合