freeMemory() 返回的是JVM堆中当前未被占用且GC未触发前可立即分配的字节数，不包含GC后释放空间、元空间或堆外内存，不能用于实时监控或告警。
freeMemory() 返回的不是“可用内存”，而是“当前未被占用的堆内存”
Runtime.getRuntime().freeMemory() 返回的是 JVM 堆中**当前尚未被对象占用、且 GC 未触发前可立即分配的字节数**，它不包含 GC 后可能释放的空间，也不含元空间、直接内存或堆外内存。很多人误以为这是“系统剩余内存”或“还能 new 多少对象”，结果发现数值忽高忽低甚至突然归零，其实只是堆里刚好没空闲连续块了——freeMemory() 不做 GC，也不整理碎片。
常见错误现象：freeMemory() 在频繁创建短生命周期对象时持续下降，但调用 System.gc() 后也没明显回升；或者在堆快满时返回值突然跳变（比如从 20MB 跳到 150MB），其实是 GC 完成后堆重新统计的结果。
- 它只反映堆内已知空闲区，不等于
maxMemory() - totalMemory()，三者关系是：freeMemory() ≤ totalMemory() - usedMemory，且usedMemory = totalMemory() - freeMemory()并不恒成立（因 GC 状态不同） - 不要用它判断是否该触发业务降级——它滞后、不准确、不可预测
- 若想粗略估算当前堆使用率，更稳妥的方式是：用
ManagementFactory.getMemoryMXBean().getHeapMemoryUsage()获取used和max
为什么不能靠反复调用 freeMemory() 做实时内存告警
频繁调用 freeMemory() 本身开销极小，但它的值变化毫无节奏感：GC 未发生时它缓慢减少；一次 Young GC 后可能猛增；Full GC 后又可能骤降（因晋升失败或元空间膨胀）。它不具备单调性或周期性，无法构成可靠的时间序列信号。
典型误用场景：在 HTTP 请求入口加一行日志打印 freeMemory()，然后按阈值发钉钉告警。结果是白天每分钟告警 20 次，晚上安静如鸡——不是内存健康了，是流量低、GC 少、空闲块没被填满而已。
- 告警应基于
MemoryUsage.used占MemoryUsage.max的百分比，且需连续 N 次超阈值（比如 85% × 3 次）才触发 - 必须排除 GC 刚结束的“虚假低谷”：可通过
GarbageCollectorMXBean监听Notification，在 GC 完成后延时 1–2 秒再采样 - JVM 参数影响极大：若用了 ZGC 或 Shenandoah，
freeMemory()可能长期稳定在高位，不代表堆宽松，只是回收机制不同
替代方案：用 MemoryMXBean + UsageThreshold 实现轻量监控
真正适合生产环境的内存监控，不是轮询 freeMemory()，而是注册堆内存使用率阈值监听。JVM 内置支持当堆使用量超过设定值时主动发通知，响应及时、无轮询开销、不干扰 GC。
实操建议：
- 获取
MemoryMXBean：ManagementFactory.getMemoryMXBean() - 设置阈值（例如 80%）：
memoryBean.setUsageThreshold((long) (memoryBean.getHeapMemoryUsage().getMax() * 0.8)) - 添加
NotificationListener监听MEMORY_THRESHOLD_EXCEEDED事件，收到即记录堆详情、dump 线程或触发告警 - 注意：该阈值只对 heap 生效，非堆内存（如 Metaspace）需单独用
MemoryPoolMXBean配置
示例关键片段：
MemoryMXBean memoryBean = ManagementFactory.getMemoryMXBean();
memoryBean.setUsageThreshold(1024L * 1024 * 1024); // 1GB 绝对阈值
NotificationEmitter emitter = (NotificationEmitter) memoryBean;
emitter.addNotificationListener((notification, handback) -> {
if ("java.management.memory.threshold.exceeded".equals(notification.getType())) {
System.out.println("Heap usage exceeded: " + memoryBean.getHeapMemoryUsage());
}
}, null, null);
freeMemory() 唯一靠谱的用途：调试阶段快速验证 GC 效果
在本地压测或排查内存泄漏时，freeMemory() 可以作为辅助观察项，但必须配合 GC 显式触发和多次采样。它不适合线上，但在开发机上跑一个循环，看 GC 前后数值落差，比看 GC 日志更直观。
- 正确用法示例：
System.gc(); Thread.sleep(100); long f1 = Runtime.getRuntime().freeMemory(); doWork(); System.gc(); Thread.sleep(100); long f2 = Runtime.getRuntime().freeMemory(); System.out.println("GC 回收了 " + (f2 - f1) + " 字节"); - 必须加
Thread.sleep(100)，否则 GC 线程可能还没完成统计，freeMemory()返回旧快照 - OpenJDK 17+ 中，
System.gc()默认被禁用（-XX:+DisableExplicitGC），此时freeMemory()更难体现变化，需确认 JVM 启动参数 - 如果
f2 - f1持续变小（比如从 50MB → 5MB → 0），说明对象在不断晋升到老年代，或存在弱引用未清理，这时该去查jstat -gc或 heap dump
线上环境几乎不需要知道这个数字——你需要的是“堆用了多少”“什么时候会 OOM”“哪类对象占得多”，而不是“此刻堆里还剩多少字节没填”。把精力放在 MemoryUsage、GC 日志和 jmap 上，比盯着 freeMemory() 有效得多。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
