%memused高但available大是因sar统计不区分可回收内存，而available包含可换出匿名页等弹性空间；AnonPages高未必有压力，需结合active/inactive比例、swap活动、OOM及应用表现综合判断。
这是 Linux 内存管理中一个常见但容易误解的现象：sar -r 显示 %memused 很高（比如 95%+），而 free -h 却显示 available 值很大（比如还有 8GB 可用），同时 /proc/meminfo 中的 AnonPages 数值偏高。这并不一定表示内存真的“吃紧”，而是反映了内核对“已使用”和“可用”内存的不同统计逻辑。
为什么 %memused 高但 available 很多？
sar -r 的 %memused 计算方式简单粗暴：它用 Total - Free - Buffers - Cached（即传统意义上的“已用内存”）除以总内存，**不考虑可回收的 page cache、slab、anon pages 是否实际被锁定或活跃**。而 free -h 的 available 是内核 3.14+ 引入的更智能估算值，它综合了：
- 真正空闲页（
MemFree） - 可快速回收的 page cache（非 dirty、未被锁定）
- 部分可回收的 slab（如 dentries/inodes）
- 可换出的匿名页（如果 swap 启用且策略允许）
所以即使 AnonPages 较大（例如 Java 应用分配了大量堆），只要这些页当前不活跃、未被访问，内核仍认为它们是“潜在可用”的——available 就包含了这部分弹性空间。
AnonPages 高但系统没压力？看 active/inactive 比例
高 AnonPages 本身不是问题，关键看这些匿名页是否“热”。可通过以下命令判断：
cat /proc/vmstat | grep -E "pgpgin|pgpgout|pgmajfault|pgpgin|pgpgout" —— 若 pgmajfault（缺页中断）持续升高，说明进程频繁触发换入，可能真缺内存；
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
grep -i "active\|inactive" /proc/meminfo —— 关注 Inactive(anon) 和 Active(anon)。若 Inactive(anon) 远大于 Active(anon)，说明大部分匿名页近期未被访问，内核随时可将其换出或回收（尤其开启 vm.swappiness > 0 时）。
如何确认是否存在真实内存压力？
别只盯数字，看行为：
-
OOM killer 是否触发？
dmesg -T | grep -i "killed process"—— 出现即严重内存争用 -
swap 使用是否增长？
swapon --show或cat /proc/swaps，结合si/so字段（sar -B）看每秒换入换出量 -
内存分配延迟是否上升？
cat /proc/zoneinfo | grep -A5 "node.*Normal" | grep "spill"或观察/proc/vmstat中pgalloc与pgfail差值 -
应用响应是否变慢？ 如 JVM GC 时间突增、数据库查询延迟升高，再结合
pidstat -r -p <pid></pid>看单进程 RSS 和 %MEM
什么情况下需要干预？
仅 %memused 高 + AnonPages 高，但 available > 10%、无 swap 活动、无 OOM、应用正常 —— 无需操作。这是内核高效利用内存的表现。
需关注的情形：
- 有 swap 且
si（swap-in）持续 > 100 KB/s，同时available持续低于 5% → 考虑加内存或优化应用内存使用 -
AnonPages接近CommitLimit（cat /proc/meminfo | grep Commit），且Committed_AS不断上涨 → 存在内存过度承诺风险，检查是否有内存泄漏进程（ps aux --sort=-%mem | head -10） - Java 等应用
rss远高于heap（jstat -gc <pid></pid>对比），且Anonymous在pmap -x <pid></pid>中占比高 → 可能存在 native memory 泄漏（如 DirectByteBuffer、JNI）
