%memused高但available大是因sar统计不区分可回收内存，而available包含可换出匿名页等弹性空间；AnonPages高未必有压力，需结合active/inactive比例、swap活动、OOM及应用表现综合判断。
这是 Linux 内存管理中一个常见但容易误解的现象：
显示
很高（比如 95%+），而
却显示
值很大（比如还有 8GB 可用），同时
中的
数值偏高。这并不一定表示内存真的“吃紧”，而是反映了内核对“已使用”和“可用”内存的不同统计逻辑。
为什么 %memused 高但 available 很多？
的
计算方式简单粗暴：它用
（即传统意义上的“已用内存”）除以总内存，**不考虑可回收的 page cache、slab、anon pages 是否实际被锁定或活跃**。而
的
是内核 3.14+ 引入的更智能估算值，它综合了：
真正空闲页（
）
可快速回收的 page cache（非 dirty、未被锁定）
部分可回收的 slab（如 dentries/i
node
s）
可换出的匿名页（如果 swap 启用且策略允许）
所以即使
较大（例如 Java 应用分配了大量堆），只要这些页当前不活跃、未被访问，内核仍认为它们是“潜在可用”的——
就包含了这部分弹性空间。
AnonPages 高但系统没压力？看 active/inactive 比例
高
本身不是问题，关键看这些匿名页是否“热”。可通过以下命令判断：
—— 若
（缺页中断）持续升高，说明进程频繁触发换入，可能真缺内存；
Eclipse导入Android或其他的JAVA项目的正确方法 WORD版
本文档主要讲述的是Eclipse导入Android或其他的JAVA项目的正确方法；希望本文档会给有需要的朋友带来帮助；感兴趣的朋友可以过来看看
下载
—— 关注
和
。若
远大于
，说明大部分匿名页近期未被访问，内核随时可将其换出或回收（尤其开启
时）。
如何确认是否存在真实内存压力？
别只盯数字，看行为：
OOM killer 是否触发？
—— 出现即严重内存争用
swap 使用是否增长？
或
，结合
字段（
）看每秒换入换出量
内存分配延迟是否上升？
或观察
中
与
差值
应用响应是否变慢？
如 JVM GC 时间突增、数据库查询延迟升高，再结合
看单进程 RSS 和 %MEM
什么情况下需要干预？
仅
高 +
高，但
、无 swap 活动、无 OOM、应用正常 ——
无需操作
。这是内核高效利用内存的表现。
需关注的情形：
有 swap 且
（swap-in）持续 > 100 KB/s，同时
持续低于 5% → 考虑加内存或优化应用内存使用
接近
（
），且
不断上涨 → 存在内存过度承诺风险，检查是否有内存泄漏进程（
）
Java 等应用
远高于
（
对比），且
在
中占比高 → 可能存在 native memory 泄漏（如 DirectByteBuffer、JNI）
sar -r%memusedfree -havailable/proc/meminfoAnonPagessar -r%memusedTotal - Free - Buffers - Cachedfree -havailableMemFreeAnonPagesavailableAnonPagescat /proc/vmstat | grep -E "pgpgin|pgpgout|pgmajfault|pgpgin|pgpgout"pgmajfaultgrep -i "active\|inactive" /proc/meminfoInactive(anon)Active(anon)Inactive(anon)Active(anon)vm.swappiness > 0dmesg -T | grep -i "killed process"swapon --showcat /proc/swapssi/sosar -Bcat /proc/zoneinfo | grep -A5 "node.*Normal" | grep "spill"/proc/vmstatpgallocpgfailpidstat -r -p %memusedAnonPagesavailable > 10%siavailableAnonPagesCommitLimitcat /proc/meminfo | grep CommitCommitted_ASps aux --sort=-%mem | head -10rssheapjstat -gc Anonymouspmap -x