我先给结论，再说明它在项目里解决什么问题。线程私有区、共享区与常见内存异常。主要包括程序计数器、虚拟机栈、本地方法栈、堆和方法区。

核心机制我会按一次真实执行过程来讲。沿着「类加载建立元数据 → 线程创建私有栈 → 对象分配进入堆 → 方法执行创建栈帧 → GC 与卸载回收区域」观察输入、状态与输出，这些阶段都可以从日志、指标或源码里验证。 类加载建立元数据 类元数据、运行时常量池和方法信息主要进入方法区的具体实现 Metaspace，Class 对象仍位于堆。 线程创建私有栈 每个线程拥有程序计数器和 Java 虚拟机栈，线程数直接影响本地内存与栈容量。

实现细节只抓关键入口，不会整段背源码。jcmd VM.nativememory summary：堆外分类总账。 jcmd GC.heapinfo / VM.classloaderstats：堆与类加载器证据。 我会先确认请求实际走到了哪条路径，再用运行数据验证，不会只看类名或配置猜测。

放到生产使用时，我会关注参数和验证数据。在同一容器限制下逐步增加线程、DirectByteBuffer 和动态类，记录 Heap、Metaspace、Thread、Code 与 RSS 的差值。 固定输入和基线 先在没有故障注入的环境执行上述配置，固定数据规模、并发度、运行时版本和预热时间。以「Xmx/容器」为主基线，记录值应满足「示例不超过 60%」；同时保存 Heap committed/used、线程数与栈预算，使后续变化能够回到同一时间轴比较。

最后补充常见误区和使用边界。团队只关注 -Xmx，忽略每个线程的 -Xss、直接内存、Metaspace 和 native 库。线程数上升后 RSS 超过容器限制，尚未发生 Java 堆 OOM 就被 OOM Killer 终止。容量设计应从进程总内存反推各区域预算。 只看堆忽略进程总 RSS：Heap committed/used：建立进程内存预算表。 方案：更适合的场景：主要收益：代价与边界。 Java 堆：普通对象与数组：GC 自动管理、容量可观测：过大增加停顿与 RSS。 线程栈：每线程调用帧与局部状态：线程隔离、随线程释放：线程多时总量显著，过小易栈溢出。 直接/本地内存：NIO、JIT、类元数据与 native 组件：减少部分复制或承载 JVM 自身：不完全受 Xmx 约束。