<p>Runtime类仅提供堆内存粗粒度视图，不包含元空间、直接内存等非堆区域；totalMemory()是JVM已申请的堆总量，maxMemory()是-Xmx设定的堆上限（容器中可能受cgroup限制）；freeMemory()不代表真实可用内存，因忽略碎片化，不可用于资源预分配；监控堆使用率应计算( totalMemory() - freeMemory() ) / maxMemory()，但需注意maxMemory()为Long.MAX_VALUE时的特殊处理；细粒度内存分析须借助java.lang.management包中的MXBean接口。</p>
Runtime 类能拿到 JVM 当前内存使用概况，但注意：它只提供**堆内存的粗粒度视图**，不包含元空间、直接内存、线程栈等非堆区域，也不能反映 GC 后的真实可用空间。
getRuntime().totalMemory() 和 maxMemory() 的真实含义
totalMemory() 返回的是 JVM **当前已向操作系统申请、并由 JVM 管理的堆内存总量**（单位字节），不是“已用”，也不是“最大”。它会随 GC 或堆扩容/缩容动态变化；maxMemory() 是 JVM 启动时通过 -Xmx 设定的堆上限（若未设，则为默认值），这个值在运行期基本不变（除非用 JMX 显式调整，且 JVM 支持）。
- 常见误解：
totalMemory() - freeMemory()≈ 当前已用堆内存 —— 这个计算在多数场景下成立，但 GC 触发后freeMemory()可能突增，而totalMemory()不一定立刻下降 - 如果应用频繁创建大对象导致
totalMemory()接近maxMemory()，说明堆有压力，但需结合 GC 日志判断是否真要调大-Xmx -
maxMemory()在容器环境可能被-XX:+UseContainerSupport（JDK 8u191+ / JDK 10+ 默认开启）识别为 cgroup memory limit，此时它未必等于启动参数里的-Xmx
freeMemory() 不等于“空闲可用内存”
freeMemory() 返回的是**当前堆中尚未被任何对象占用、且 JVM 认为可立即分配的空间字节数**。但它不考虑碎片化，也不代表你能成功 new 出一个同样大小的对象 —— 尤其在老年代碎片严重时，即使 freeMemory() 数值不小，也可能因无法找到连续空间而触发 Full GC 或 OOM。
- 不要用
freeMemory()做资源预分配决策（比如“还有 50MB 就开新任务”），它太乐观 - 它的值在 Minor GC 后通常会明显上升，在 Full GC 后可能大幅上升或基本不变（取决于是否压缩）
- 对比
Runtime.getRuntime().gc()后再调freeMemory()并不可靠：GC 是异步的，gc()只是建议，不保证执行，更不保证完成
如何安全地获取近似堆使用率
想监控堆水位？别只看单次 freeMemory()，应组合三个值算比率，并采样观察趋势：
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
立即学习“Java免费学习笔记（深入）”；
Runtime rt = Runtime.getRuntime(); long used = rt.totalMemory() - rt.freeMemory(); long max = rt.maxMemory(); double usageRate = (double) used / max;
- 分母必须用
maxMemory()，而不是totalMemory()—— 后者波动太大，比率失去参考意义 - 如果
maxMemory()返回Long.MAX_VALUE（例如没设-Xmx），说明堆可无限制增长，此时用totalMemory()做分母更合理，但需警惕 OOM 风险 - 该比率仅反映堆，
OutOfMemoryError: Metaspace或OutOfMemoryError: Direct buffer memory完全不会体现在这个数字里
真正需要细粒度内存数据时该用什么
当你要区分年轻代/老年代、查看 Metaspace 使用量、跟踪直接内存、或获取 GC 统计时，Runtime 就不够用了。得切到 java.lang.management 包：
- 用
ManagementFactory.getMemoryMXBean()获取整体内存池状态 - 用
ManagementFactory.getMemoryPoolMXBeans()遍历各内存池（如PS Eden Space、Compressed Class Space） - 用
BufferPoolMXBean查直接内存（ByteBuffer.allocateDirect()分配的部分） - JVM 启动加
-XX:+PrintGCDetails -Xlog:gc*才能看到真实 GC 行为与内存变化因果
别把 Runtime 当万能内存仪表盘 —— 它只是入门级快照，真要定位内存问题，得往下挖一层。
