堆与非堆内存占用比例需基于MemoryUsage的used/comitted计算：堆使用率=heap.used/heap.committed，非堆使用率≈(metaspace+codeCache+compressedClassSpace).used之和/(对应).committed之和，直接内存需单独通过BufferPoolMXBean获取。
要分析堆与非堆内存的占用比例，核心是获取 MemoryUsage 实例中 used 值的对比关系——不是看绝对大小，而是看两者在各自“已提交”（committed）范围内的实际使用占比，以及它们对总 JVM 内存压力的相对贡献。
如何准确获取堆与非堆的 MemoryUsage
Java 提供了标准管理接口，无需第三方依赖：
- 通过
ManagementFactory.getMemoryMXBean()获取堆内存整体使用情况（getHeapMemoryUsage()） - 通过
ManagementFactory.getMemoryPoolMXBeans()遍历所有内存池，筛选出属于非堆的池，例如：
•Code Cache（JIT 编译代码）
•Metaspace（JDK 8+ 替代永久代，存类元数据）
•Compressed Class Space（可选，配合压缩类指针）
•Direct Buffer Memory（需通过BufferPoolMXBean单独获取，不属于 MemoryPoolMXBean）
关键指标含义与计算逻辑
MemoryUsage 的四个字段中，用于比例分析的只有 used 和 committed：
- used：当前真实占用字节数，是计算“实际使用率”的分子
-
committed：JVM 当前保证可用的内存上限，是分母——注意不能用
max，因为 Metaspace 的 max 默认为Long.MAX_VALUE，无实际约束意义 - 堆使用率 =
heapUsage.used / heapUsage.committed - 非堆总使用率 ≈
(metaspace.used + codeCache.used + compressedClassSpace.used) / (metaspace.committed + codeCache.committed + compressedClassSpace.committed) - 若需评估直接内存影响，额外加上
DirectByteBuffer的used，但它的 committed 不单独暴露，通常以 used 值直接计入非堆压力参考
为什么非堆占用比例可能更高？常见诱因
非堆内存虽不存业务对象，但极易被忽视地膨胀：
-
类加载爆炸：热部署、OSGi、动态代理（如 CGLIB）、大量反射调用 → Metaspace 持续增长，尤其未设置
-XX:MaxMetaspaceSize时会无限申请物理内存 -
直接缓冲区泄漏：NIO 中
allocateDirect()后未显式cleaner或未关闭 channel → 内存驻留非堆，GC 不清理 -
JIT 缓存堆积：高频方法反复编译/去优化 → Code Cache 占用飙升，超限时触发
UseCompiler禁用，性能骤降 -
线程栈累积：虽然线程栈本身不归入 MemoryPool，但
ThreadMXBean可查总栈预留量；线程数多、-Xss大 → 非堆底层内存压力显著
实用建议：一次到位的监控脚本思路
写一个简易诊断工具，每 5 秒打印一次关键比值（单位 MB，保留一位小数）：
- 堆使用率 =
heap.used / heap.committed × 100% - Metaspace 使用率 =
meta.used / meta.committed × 100% - CodeCache 使用率 =
code.used / code.committed × 100% - 非堆总用量（MB）=
meta.used + code.used + compressed.used + direct.used（后一项需从BufferPoolMXBean获取） - 同步输出线程数和平均栈大小，辅助判断栈内存是否异常
当发现非堆使用率持续 >85% 或非堆总用量 > 堆 committed，就该优先排查类加载器泄漏或直接内存未释放问题。
