Runtime.maxMemory() 返回 JVM 堆内存理论上限（字节），对应 -Xmx 设置值，不随运行时变化，不含非堆内存，非系统剩余内存，不能用于判断 OOM。
Runtime.maxMemory() 返回的是当前 JVM 进程堆内存的理论上限，单位是字节，它直接对应启动参数 -Xmx 的设置值（未显式配置时取默认值，如 JDK 8 默认约 64MB，JDK 11+ 默认为物理内存的 1/4）。这个值不是操作系统剩余内存，也不是 JVM 实际已用或已分配的内存，而是“最多能向 OS 申请多少堆空间”的硬性边界。
maxMemory() 的实际含义与典型取值
它反映的是 JVM 堆（Heap）的最大容量，不包括 Metaspace、CodeCache、直接内存（Direct Buffer）、线程栈等非堆区域。常见情况如下：
- 未设
-Xmx：JVM 按规则自动推导，例如在普通桌面环境可能为 256MB 或 512MB；在容器中若未启用容器感知（如 JDK 8 缺少-XX:+UseContainerSupport），可能错误地取宿主机总内存的 1/4，导致远超容器限制 - 显式设置
-Xmx2g：maxMemory() 理论上返回约2 * 1024 * 1024 * 1024 = 2147483648字节（注意单位换算） - JDK 10+ 默认开启容器内存感知，Docker 中若设
--memory=1g且未覆盖-Xmx，maxMemory() 通常会接近 1GB（需确认 GC 类型与版本兼容性）
如何正确调用与解读
只需一次获取 Runtime 实例即可，无需反复调用 getRuntime()：
Runtime rt = Runtime.getRuntime();
long maxBytes = rt.maxMemory(); // 始终返回同一 JVM 实例的固定上限值
System.out.println("最大堆内存：" + maxBytes / 1024 / 1024 + " MB");
注意：该值在 JVM 启动后即确定，运行时不会变化。若发现返回值明显小于预期（如容器中只显示 2GB，但 --memory 设为 8GB），应检查是否启用了容器支持，或是否存在 -Xmx 显式覆盖。
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
立即学习“Java免费学习笔记（深入）”；
常见误判与规避方式
很多人误把 maxMemory() 当作“当前可用内存”或“系统空闲内存”，这是错误的：
- 它和操作系统剩余内存完全无关，仅描述 JVM 自身堆的策略上限
- 它不保证 JVM 一定能成功申请到这么多内存——当系统资源不足、cgroup 限制生效或内存碎片严重时，仍可能触发 OOM
- 不能用它判断是否即将 OOM，真正危险信号应结合
totalMemory() - freeMemory()的增长趋势、GC 频率及日志中的java.lang.OutOfMemoryError: Java heap space
配合其他方法做合理估算
单看 maxMemory() 信息有限，建议组合使用：
-
rt.totalMemory()：当前已向 OS 申请并初始化的堆大小（即已 commit 的堆） -
rt.freeMemory()：这部分已 commit 但尚未被对象占用的堆空间（注意：含 GC 暂未回收对象） - 粗略“当前活跃堆用量” ≈
rt.totalMemory() - rt.freeMemory()，但该值不含元空间、直接内存等，仅作参考
如需生产级监控，应优先使用 JMX 的 MemoryUsage 或 Micrometer + Prometheus，而非仅依赖 Runtime 方法。
