如何使用 Runtime 类获取当前 Java 虚拟机的内存信息-java教程-PHP中文网

runtime类仅提供堆内存粗粒度视图，不包含元空间、直接内存等非堆区域；totalmemory()是jvm已申请的堆总量，maxmemory()是-xmx设定的堆上限（容器中可能受cgroup限制）；freememory()不代表真实可用内存，因忽略碎片化，不可用于资源预分配；监控堆使用率应计算( totalmemory() - freememory() ) / maxmemory()，但需注意maxmemory()为long.max_value时的特殊处理；细粒度内存分析须借助java.lang.management包中的mxbean接口。

如何使用 runtime 类获取当前 java 虚拟机的内存信息

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。

Gradle 9.8.0

下载

不要用 freeMemory() 做资源预分配决策（比如“还有 50MB 就开新任务”），它太乐观
它的值在 Minor GC 后通常会明显上升，在 Full GC 后可能大幅上升或基本不变（取决于是否压缩）
对比 Runtime.getRuntime().gc() 后再调 freeMemory() 并不可靠：GC 是异步的，gc() 只是建议，不保证执行，更不保证完成

如何安全地获取近似堆使用率

想监控堆水位？别只看单次 freeMemory()，应组合三个值算比率，并采样观察趋势：

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 行为与内存变化因果