Runtime.getRuntime().totalMemory() 不是真实内存使用量，它仅表示JVM已申请的堆容量，不含实际占用、GC碎片、元空间及直接内存；正确估算需结合freeMemory()和maxMemory()，并建议用JMX或Micrometer等专业工具监控。
Runtime.getRuntime().totalMemory() 不是内存监控的可靠指标，它返回的是 JVM 当前已从操作系统申请到、但未必被 Java 对象实际占用的堆内存总量。直接用它判断“程序用了多少内存”会严重误判。
为什么 totalMemory() 不能反映真实内存使用
这个值本质上是 JVM 堆的已分配容量（即 -Xms 初始值和后续扩容后的当前上限），不是已使用量。即使你刚启动一个空 Spring Boot 应用，totalMemory() 也可能显示 256MB——但这不代表用了 256MB，可能只用了 30MB。
常见误用场景：
- 在循环里反复调用
totalMemory()并画曲线，结果看到“内存稳步上涨”，其实是 JVM 按需扩容，不是泄漏 - 用它减去
freeMemory()算“已用内存”，但freeMemory()返回的是堆内未被分配的对象空间，不包含 GC 后的碎片、元空间、直接内存等 - 对比不同 JVM 参数下的
totalMemory()值，误以为数值小就更省内存
真正该看的三个 Runtime 方法组合
要粗略估算 Java 堆的实际活跃内存，必须三者配合：
-
Runtime.getRuntime().totalMemory()：当前堆总容量（已分配） -
Runtime.getRuntime().freeMemory()：当前堆中尚未被任何对象占用的空间（注意：不是 GC 后的可用空间） -
Runtime.getRuntime().maxMemory()：堆最大可扩容上限（对应-Xmx）
所以近似“已用堆内存” = totalMemory() - freeMemory()，但这个值仍含 GC 暂时未回收的对象，且不含非堆内存。示例：
long used = runtime.totalMemory() - runtime.freeMemory();
System.out.println("Approx used heap: " + used / 1024 / 1024 + " MB");注意：这个计算必须在 GC 后做才稍有意义，否则大量待回收对象会让结果虚高。
比 Runtime 更靠谱的监控方式
生产环境别依赖 Runtime 手动轮询。优先用标准机制：
- JVM 自带 JMX：通过
java.lang:type=MemoryMBean 读取used、committed、max属性，它们区分堆/非堆、已使用/已提交，语义明确 - Metrics 类库（如 Micrometer）：自动采集
jvm.memory.used等指标，天然支持 Prometheus 抓取 - JDK 自带工具：启动时加
-XX:+PrintGCDetails -Xlog:gc*，或运行时用jstat -gc <pid>查看各代实时使用量 - VisualVM / JConsole：连接后直接看 Memory 面板，底层也是走 JMX，但带图形和历史趋势
如果硬要在代码里埋点，至少封装成定时任务，并搭配 System.gc()（仅调试用）或显式触发一次 GC 后再采样——但要注意 System.gc() 是建议而非强制，JVM 可能忽略。
真正难监控的从来不是堆内存总量，而是对象引用链、GC Roots 持有关系、直接内存泄漏、线程本地变量堆积。这些 Runtime 根本看不到，得靠 heap dump + MAT 或 JFR 事件分析。
