%MEM 加起来远超100%是正常的，因其基于MemAvailable计算且RSS存在共享页重复计数；应优先关注MemAvailable值、用slabtop和pcstat定位内存归属，并结合NativeMemoryTracking分析Java native内存。
top 和 ps 看到的 %MEM 为什么加起来不等于总内存？
Linux 的 %MEM 是进程占用物理内存（RSS）占系统总可用内存（/proc/meminfo 中的 MemAvailable）的百分比，不是占 MemTotal；而且多个进程可能共享内存页（如共享库、fork 后的 copy-on-write），RSS 直接相加会重复计算。所以 top 里所有进程 %MEM 加起来远超 100% 很正常。
- 优先看
top右上角的Mem:行——重点关注available值，它才是真正可立即分配的内存，比free更准确 - 用
ps aux --sort=-%mem | head -10快速定位内存大户，但注意 RSS 不含 page cache，真实压力可能藏在缓存行为里 - 别迷信
%MEM排序结果：一个 Java 进程 RSS 2GB，可能只用了 500MB 堆，其余是 Metaspace、直接内存或 native 内存泄漏
如何区分是应用泄漏还是内核/缓存吃掉了内存？
先跑 cat /proc/meminfo，重点对比三组值：MemAvailable vs MemFree（差值大说明 page cache 或 slab 占得多）；Cached vs SwapCached（前者是文件页缓存，通常无害；后者是已换出又读回的页，可能预示 swap 频繁）；Slab 和 SReclaimable（若 Slab 高但 SReclaimable 低，可能是内核对象泄漏，比如 nf_conntrack、dentry）。
- 查 slab 占用：用
slabtop -o按OBJS排序，关注ext4_inode_cache、nf_conntrack、dentry等异常高的项 - 查 page cache 归属：用
pcstat（需安装）或vmtouch -v /path/to/file看具体文件是否被缓存；也可临时执行echo 1 > /proc/sys/vm/drop_caches（仅测试用，生产慎用）观察MemAvailable是否明显回升 - 确认是否真缺内存：如果
MemAvailable> 5%MemTotal且无 OOM killer 日志（dmesg -T | grep -i "killed process"），那大概率不是“缺内存”，而是内存被合理利用了
Java 进程 RSS 远高于 -Xmx，怎么定位 native 内存去哪了？
JVM 的 -Xmx 只控制堆，而 RSS 包含堆、Metaspace、CodeCache、线程栈、DirectByteBuffer、JNINative、GC 本身开销等。RSS 比堆大 1.5–3 倍常见，但翻倍再翻倍就得查了。
- 开启 JVM 本机内存追踪：启动时加
-XX:NativeMemoryTracking=detail，运行中用jcmd <pid> VM.native_memory summary查各区域用量 - 检查 DirectByteBuffer：用
jmap -histo:live <pid> | grep DirectByteBuffer看实例数；配合jstack <pid>找长期持有ByteBuffer.allocateDirect()的线程 - 警惕 JNI 库：某些数据库驱动（如 Oracle JDBC）、图像处理库（OpenCV）、Netty 的 epoll transport 都可能申请大量 native 内存，且不受 JVM 控制；用
pstack <pid>+grep -E 'mmap|mmap64|brk'可辅助判断
排查时最常被忽略的三个点
一是 docker stats 显示的内存和宿主机 top 对不上——容器 cgroup v1 默认统计包含 page cache，v2 则默认排除；查 /sys/fs/cgroup/memory/docker/<cid>/memory.stat 里的 cache 和 rss 才准。二是 df -h 显示磁盘满，但 du -sh /* 总和小很多——很可能是被删除但未释放的文件（lsof + deleted），它们仍占内存中的 page cache。三是 free -h 的 available 值受 /proc/sys/vm/vm.swappiness 影响极大：设为 0 并不禁止 swap，只是降低倾向；设为 100 会让内核更激进地换出匿名页，反而可能抬高 RSS 表观值。
