我先给结论，再说明它在项目里解决什么问题。从容器总内存拆分 Heap、Metaspace、Direct Memory、线程栈和系统余量。JVM 内存配置不能只设置 Xmx，应从容器或机器总内存反推，给 Java Heap、Metaspace、Direct Memory、线程栈、Code Cache、JVM Native 内存和安全余量分别预留空间；再根据对象存活、分配速率、GC 目标和压测结果调整，而不是照搬固定比例。

核心机制我会按一次真实执行过程来讲。JVM 内存配置不能只设置 Xmx，应从容器或机器总内存反推，给 Java Heap、Metaspace、Direct Memory、线程栈、Code Cache、JVM Native 内存和安全余量分别预留空间；再根据对象存活、分配速率、GC 目标和压测结果调整，而不是照搬固定比例。

实现细节只抓关键入口，不会整段背源码。-XX:MaxRAMPercentage：容器感知堆比例。 jcmd VM.nativememory：Heap 外各分类。 我会先确认请求实际走到了哪条路径，再用运行数据验证，不会只看类名或配置猜测。

放到生产使用时，我会关注参数和验证数据。在 2/4/8GiB 容器规格分别压测峰值，记录 RSS、GC 后堆、直接内存和线程栈，验证参数随规格缩放。 固定输入和基线 先在没有故障注入的环境执行上述配置，固定数据规模、并发度、运行时版本和预热时间。以「RSS 峰值/limit」为主基线，记录值应满足「<80% 示例」；同时保存 进程 RSS 峰值、GC 后堆基线，使后续变化能够回到同一时间轴比较。

最后补充常见误区和使用边界。应用压测时堆只用到 1.5GiB，进程仍被系统杀死，因为直接内存、线程栈和 Metaspace 把 RSS 推过限制。重新建立总内存预算表，把 Xmx 调到约 60% 并限制线程和直接内存后才稳定。 Xmx 占满容器不给堆外留余量：进程 RSS 峰值：从容器限制反推 Xmx。 线程增长导致本地内存耗尽：GC 后堆基线：预留 20%+故障余量。 内存参数必须形成总账：容器限制大于堆、Metaspace、线程栈、直接内存、JIT/GC native 开销和安全余量之和。