Runtime.freeMemory() 单独使用不可靠，因其仅反映已分配堆中未用部分，而非整体堆剩余容量；正确水位指标应为 (totalMemory - freeMemory) / maxMemory，即已用堆占最大堆比例。
Runtime.freeMemory() 不能准确反映“堆内存剩余水位”，直接用它做预警极易误报或漏报，必须配合 totalMemory() 和 maxMemory() 综合计算，并理解其局限性。
为什么 freeMemory() 单独使用不可靠
它返回的是 JVM 当前已分配堆内存中尚未使用的字节数，不是“整个堆还剩多少能用”。JVM 不会把所有堆空间一次性全分配给应用——totalMemory() 是当前实际向操作系统申请并由 JVM 管理的堆大小，而 maxMemory() 才是堆上限（-Xmx 设置值）。
例如：即使堆上限是 2GB，刚启动时 totalMemory() 可能只有 256MB，此时 freeMemory() 再大，也说明不了整体水位高低。
正确计算“可用堆占比”的公式
真正有意义的水位指标是：
（totalMemory - used） / maxMemory，其中 used = totalMemory() - freeMemory()。
等价写法（更常用）：
(Runtime.getRuntime().totalMemory() - Runtime.getRuntime().freeMemory()) / (double) Runtime.getRuntime().maxMemory()
这个比值代表已用堆占最大堆容量的比例，才是判断是否接近 OOM 的合理依据。
轻量级轮询监控 + 阈值预警示例
- 用单独线程每 3–5 秒采样一次，避免高频调用影响性能
- 设定分级阈值，比如：≥75% 打 warning 日志，≥90% 发告警（邮件/钉钉）、dump 堆快照（
jmap -dump:format=b,file=heap.hprof） - 注意规避 GC 干扰：采样前可先调用
System.gc()（仅作参考，不保证触发），或连续多次采样取稳定值；生产环境更推荐依赖 JMX 或 Prometheus + jvm_exporter
比 Runtime 更靠谱的替代方案
-
JMX 接口：通过
java.lang:type=Memory获取Usage.used和Usage.max，数据更准、支持远程获取 -
GC 日志分析：开启
-Xlog:gc*:file=gc.log，关注每次 GC 后的 “After GC” 堆占用，反映真实压力 - Arthas 或 VisualVM：运行时动态查看内存池（Eden/Survivor/Old）分布，定位泄漏对象
