totalmemory()返回jvm已向操作系统申请的当前堆内存总量（已提交堆大小），freememory()返回其中尚未被对象占用的部分；二者差值即当前已使用的堆内存。
Runtime.getRuntime().totalMemory() 和 freeMemory() 返回值到底代表什么
这两个方法返回的是 JVM 堆内存的当前快照，不是整个进程的物理内存占用。totalMemory() 是 JVM 向操作系统申请到的、**已分配但未必全部在用**的堆内存上限（即“已提交堆大小”），freeMemory() 是其中**尚未被对象占用的部分**——注意，它不等于 totalMemory() - usedMemory，因为 GC 后会有碎片，且部分内存可能被保留为“预留但未提交”状态。
真正反映应用实际堆使用量的是： totalMemory() - freeMemory()，也就是当前已使用的堆内存（used memory）。这个值会随对象分配和 GC 波动，不能直接等同于 RSS 或 VSS。
- 如果刚启动就调
freeMemory()，值可能很大，不代表空闲资源多，只是堆还没扩张 -
maxMemory()才是 -Xmx 设定的理论上限（若未设，则为平台默认值），但实际totalMemory()可能远小于此——JVM 懒加载堆空间 - 监控时务必用差值计算 used，别只盯
freeMemory()单独变化
为什么直接轮询 Runtime 不足以反映真实内存压力
单纯每秒打一次 totalMemory() 和 freeMemory()，看到数字上涨就认为“内存泄漏”，大概率误判。因为：
- JVM 会在 GC 后收缩堆（尤其 G1/CMS 的 InitiatingOccupancyFraction 触发前），
totalMemory()可能回落，freeMemory()突然变大——这不是内存释放，是堆收缩 - 非堆内存（Metaspace、CodeCache、DirectByteBuffer、线程栈）完全不被
Runtime覆盖，而它们常是 OOM 元凶（比如java.lang.OutOfMemoryError: Metaspace） - native 内存泄漏（如 JNI 调用未释放 malloc、Netty 的
PooledByteBufAllocator配置不当）也不会体现在Runtime数据里
所以，Runtime.getRuntime() 只适合粗粒度观察堆分配趋势，不能替代 jstat -gc、jcmd <pid> VM.native_memory summary</pid> 或 JMX 的 MemoryUsage 属性。
用 Runtime 监控的最小可行代码模板（带防抖与单位转换）
以下代码避免高频采样干扰 GC，也防止日志刷屏，同时把字节转成 MB 并保留一位小数：
long lastLogTime = 0;
while (running) {
long now = System.currentTimeMillis();
if (now - lastLogTime > 5_000) { // 至少间隔 5 秒
Runtime rt = Runtime.getRuntime();
long total = rt.totalMemory();
long free = rt.freeMemory();
long used = total - free;
double usedMB = used / (1024.0 * 1024.0);
double maxMB = rt.maxMemory() / (1024.0 * 1024.0);
System.out.printf("Heap used: %.1f MB / %.1f MB%n", usedMB, maxMB);
lastLogTime = now;
}
Thread.sleep(100);
}
- 不要用
System.gc()强制触发来“稳定”数值——这会干扰正常 GC 策略，且 JDK 9+ 默认禁用显式 GC - 如果要写入监控系统（如 Prometheus），建议改用 JMX Exporter，它能暴露
java.lang:type=Memory下完整的 committed/used/max，比手动轮询更准 - 注意
Runtime方法是非线程安全的，但读取本身是原子操作，无需额外同步
当看到 usedMemory 持续上涨时，下一步该查什么
Runtime 数据只是信号灯，不是诊断工具。一旦发现堆 used 持续上升且 GC 后不回落，立刻切换手段：
- 用
jstat -gc <pid> 1s</pid>看 YGC/FGC 频次、GC 后 old gen 是否增长——确认是否真泄漏还是只是缓存堆积 - 用
jmap -histo <pid></pid>快速看 top 20 类实例数，重点查byte[]、String、自定义缓存类、未关闭的流 - 导出堆快照：
jmap -dump:format=b,file=heap.hprof <pid></pid>，再用 Eclipse MAT 或 VisualVM 分析 dominator tree - 检查是否启用了
-XX:+UseContainerSupport（Docker 场景），否则maxMemory()可能读错 cgroup 限制
Runtime 提供的是“有没有问题”的提示，不是“问题在哪”的答案。越依赖它做根因分析，越容易在 Metaspace 或 off-heap 区域漏掉关键线索。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
