runtime.getruntime().maxmemory() 返回 jvm 堆内存的最大可分配容量（字节），对应 -xmx 参数设定的上限，不包括元空间、栈、直接内存等，且为固定值，不随 gc 变化。
Runtime.getRuntime().maxMemory() 返回的是 JVM **堆内存（Heap）的最大可分配容量**，单位是字节。
它反映的是 -Xmx 参数设定的上限
这个值对应启动 JVM 时通过 -Xmx 指定的最大堆大小（例如 -Xmx2g），即 Java 对象实例和数组所占用的内存区域的理论上限。注意：它不包括方法区（元空间）、栈内存、本地内存（如 DirectByteBuffer）、JVM 自身开销等。
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
不是当前已使用的堆内存
它和 usedMemory = totalMemory() - freeMemory() 不同，maxMemory() 是一个固定值（除非使用弹性堆如 ZGC 的 -XX:MaxRAMPercentage，但仍是堆上限），不会随 GC 动态变化。即使堆中大部分对象已被回收，maxMemory() 仍返回初始设定的最大值。
与 Runtime.freeMemory()、totalMemory() 的关系
-
freeMemory()：当前堆中未被使用的内存量（空闲空间） -
totalMemory()：JVM 当前向操作系统申请并已管理的堆内存总量（即已 commit 的堆大小，≤ maxMemory） -
maxMemory()：堆内存的绝对上限（即最大可 commit 大小，≤ -Xmx）
实际使用中的常见误区
- 不能用它判断“还能分配多少对象”——因为可用空间取决于
totalMemory() - usedMemory()，而totalMemory()可能远小于maxMemory() - 它不反映 Native Memory（如 JNI、DirectBuffer、CodeCache）的使用情况，OOM 原因可能是元空间或直接内存溢出，此时
maxMemory()完全无参考价值 - 容器环境下（如 Docker），若未设置 -XX:MaxRAMPercentage 等参数，
maxMemory()可能远超容器限制，导致被 kill
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
