如何使用 Runtime 类动态获取当前 JVM 虚拟机的内存分配-java教程-PHP中文网

runtime.getruntime() 返回唯一jvm实例，所有内存方法返回字节数且仅反映堆内存；freememory()非真正空闲，maxmemory()在容器中可能被低估；应优先使用memoryusage和jmx监控。

如何使用 runtime 类动态获取当前 jvm 虚拟机的内存分配

Runtime.getRuntime() 返回的是当前 JVM 实例，不是新对象

调用 Runtime.getRuntime() 每次都返回同一个 Runtime 实例，它由 JVM 在启动时初始化，不能 new，也不支持多例。误以为“每次调用都新建”会导致对内存值变化的误解——你看到的不是多个虚拟机状态，而是同一实例在不同时刻的快照。

常见错误现象：
– 在循环里反复调用 Runtime.getRuntime() 并对比 totalMemory()，发现数值几乎不变，就以为没生效；
– 把 Runtime 当作可配置对象，试图 setXXX，结果编译报错（该类无 public setter）。

只应调用一次获取引用，后续复用即可，例如：Runtime rt = Runtime.getRuntime();
所有内存相关方法（freeMemory()、totalMemory()、maxMemory()）返回字节数，需自行换算为 MB/GB 才便于观察
这些值反映的是 JVM 堆内存的分配视图，不含 Metaspace、CodeCache、直接内存等非堆区域

freeMemory()、totalMemory()、maxMemory() 的真实含义和陷阱

freeMemory() 不是“空闲可用内存”，而是“当前未被使用的堆内存”，它包含已分配但尚未被 GC 回收的对象所占空间；totalMemory() 是 JVM 当前向操作系统申请并已初始化的堆大小（即已 commit 的部分）；maxMemory() 是堆内存上限（-Xmx 设置值），但可能小于物理内存或容器限制。

典型误用场景：
– 用 freeMemory() 直接判断是否 OOM，结果发现 free 很大却仍抛 OutOfMemoryError: Java heap space；
– 认为 maxMemory() 等于 -Xmx 值，但在 JDK 8u191+ 或容器中（如 Docker），若未显式设 -XX:+UseContainerSupport，maxMemory() 可能远低于预期（比如默认取宿主机内存）。

freeMemory() + totalMemory() ≠ 当前存活对象总大小（因为有 GC 开销、碎片、TLAB 等）
maxMemory() 在容器中可能被低估：需确认是否启用容器内存感知（JDK 10+ 默认开启，JDK 8 需加 -XX:+UseContainerSupport）
若想粗略估算“还能分配多少”，更稳妥的是 rt.maxMemory() - (rt.totalMemory() - rt.freeMemory())，但这仍是近似值

配合 GC 触发看内存变化，但别依赖 System.gc()

单纯调用 System.gc() 并不能保证立即回收，JVM 只将其视为建议；而且频繁手动触发 GC 会干扰运行时行为，影响性能分析结论。真正观察内存释放，应结合 GC 日志或 JMX，而非靠 freeMemory() 跳变来“验证 GC 是否工作”。

开启 GC 日志（如 -Xlog:gc*:file=gc.log:time）比轮询 Runtime 更可靠
如果必须用代码触发并等待效果，可用 Runtime.getRuntime().gc() 后 sleep 10–50ms，再查值——仅用于调试，禁止放入生产逻辑
注意：G1/ZGC/Shenandoah 等垃圾收集器下，freeMemory() 的波动可能更平缓，不代表没回收，而是内存归还策略不同

替代方案：优先用 java.lang.management.MemoryUsage 和 JMX

Runtime 类提供的内存信息太粗粒度，且无法区分堆内各代（Eden、Survivor、Old）、也无法获取非堆数据。MemoryUsage（来自 ManagementFactory.getMemoryPoolMXBeans()）才是监控生产环境的合理起点。

示例关键路径：
– 获取老年代使用量：getUsage().getUsed() 对应 PS Old Gen 或 G1 Old Gen 的 MXBean
– 判断是否接近阈值：getUsage().getMax() 和 getUsage().getUsed() 可计算使用率
– 这些值受 GC 影响实时更新，且与 JVM 实际管理的内存池严格对应

JMX 方式可远程获取，适合集成到 Prometheus（通过 jmx_exporter）
相比 Runtime，MemoryUsage 能识别压缩指针（CompressedOops）对内存布局的影响
若在容器中运行，务必检查 MemoryUsage.getMax() 是否与 cgroup memory limit 一致，这是排查“明明 -Xmx 设得够大却 OOM”的关键线索

实际写监控逻辑时，最容易被忽略的是：JVM 启动参数与运行环境（尤其是容器）的协同。比如 -Xmx4g 在 4GiB 的 Pod 里，若未启用容器支持，maxMemory() 可能还是 256MB —— 此时看 Runtime 值只会误导你去调小堆，而不是修正 JVM 启动配置。