freeMemory() 返回已分配堆中未被使用的字节数；需结合totalMemory()和maxMemory()理解堆状态，推荐用JMX的getHeapMemoryUsage()获取更准确的已提交/已使用内存数据。
Runtime.getRuntime().freeMemory() 返回的是 JVM 堆内存中当前**尚未被使用、但已被分配（即已由 JVM 向操作系统申请）**的内存量，单位是字节。它不是“空闲物理内存”，也不是“还能再分配的最大堆空间”，而是“已分配堆中还没被对象占用的部分”。直接用它来判断“剩余可用内存”容易误解，需结合 totalMemory() 和 maxMemory() 理解。
理解三个关键方法的含义
要准确评估堆内存状态，必须同时看三个值：
- freeMemory()：已分配堆中当前未被使用的字节数（≈“堆里还空着多少”）
- totalMemory()：JVM 当前实际向操作系统申请并管理的堆总大小（≈“当前堆容量”）
-
maxMemory()：JVM 堆允许达到的最大容量（由
-Xmx决定，≈“堆顶配额”）
例如，启动时 -Xms256m -Xmx1g，刚启动可能 total=256MB，free≈240MB；随着对象创建，free 会下降，total 可能缓慢增长（直到达 max）。
实时监控的推荐写法（带单位换算和趋势参考）
以下是一个简洁实用的打印示例（可放入日志或调试循环）：
Runtime rt = Runtime.getRuntime();
long free = rt.freeMemory();
long total = rt.totalMemory();
long max = rt.maxMemory();
long used = total - free;
System.out.printf("堆使用: %.1f/%.1f MB (已用 %.1f%%), 当前分配 %.1f MB, 上限 %.1f MB%n",
used / 1024.0 / 1024.0,
max / 1024.0 / 1024.0,
(double) used / max * 100,
total / 1024.0 / 1024.0,
max / 1024.0 / 1024.0);
这样能一眼看出已用比例、是否接近上限、以及当前堆是否在动态扩容。
注意它的局限性与常见误用
- 不是 GC 实时触发器：调用它不会触发垃圾回收，返回值也不反映“马上能腾出多少”——如果有很多待回收对象但 GC 尚未运行，freeMemory() 仍会偏低
- 受 GC 策略影响大：不同 GC（如 G1、ZGC）对内存管理方式不同，freeMemory() 的波动模式也不同；一次 full GC 后 free 可能突增，但 total 未必缩回
-
不适合做内存告警主依据：更可靠的做法是监听
java.lang.management.MemoryUsage或使用GarbageCollectorMXBean获取 GC 次数/耗时，结合堆使用率（used/max）做阈值判断
替代方案：用 JMX 获取更准的“已提交/已使用”数据
若需生产环境稳定监控，建议用标准 JMX 接口：
MemoryUsage usage = ManagementFactory.getMemoryMXBean()
.getHeapMemoryUsage();
long used = usage.getUsed(); // 当前真实已用字节数
long committed = usage.getCommitted(); // 当前已提交（即 totalMemory）
long max = usage.getMax(); // 最大上限（即 maxMemory）
// free ≈ committed - used（比 freeMemory() 更贴近实际语义）
该方式与 JVM 内部统计一致，且不受 GC 瞬时状态干扰，是监控平台（如 Prometheus + JMX Exporter）的标准采集来源。
