Java对象主要分配在堆中，但经逃逸分析可栈上分配；栈只存引用和基本类型，元空间存类元数据，三者需联动监控调优。
堆是对象的唯一归属地，但不是所有对象都分配在堆上
Java 中 new 出来的对象默认分配在堆中，这是 GC 管理的主要区域。但 JIT 编译器可能通过逃逸分析判断某个对象不会被其他线程或方法访问，从而把它「栈上分配」——实际放在当前线程的 Java 虚拟机栈里，避免堆分配和后续 GC 开销。XX:+DoEscapeAnalysis（默认开启）和 XX:+EliminateAllocations 会影响该行为。注意：栈上分配的对象仍遵循栈生命周期，方法结束即销毁，不走 GC。
常见误解是“所有对象都在堆”，其实 String 字面量、Integer.valueOf(127) 返回的缓存实例等，虽然逻辑上是对象，但它们的存储位置混合了堆（对象实例）和元空间（类信息）、字符串常量池（JDK 7+ 在堆中，JDK 8+ 默认仍在堆，可通过 -XX:MaxMetaspaceSize 验证不影响它）。
Java 虚拟机栈只存局部变量和操作数，不存对象本身
每个线程独有，生命周期与线程一致。栈帧中保存的是：int、boolean 等基本类型值，以及对象的引用（Object obj 中的 obj），但 obj 指向的 new Object() 实例一定在堆中（除非被优化掉）。栈深度超限会抛 StackOverflowError，通常由无限递归或过深调用链触发；而栈内存不足（如线程过多）则可能报 OutOfMemoryError: unable to create new native thread。
关键点：
-
-Xss控制单个线程栈大小，默认 1MB（HotSpot），调小可支撑更多线程，但易触发StackOverflowError - 栈中没有 GC，也不需要 GC；它的清理靠出栈自动完成
- JNI 方法调用时，本地方法栈（Native Method Stack）独立于 Java 虚拟机栈，错误可能表现为
java.lang.UnsatisfiedLinkError
元空间替代永久代，但类元数据仍需内存，且不受堆 GC 管理
JDK 8 开始，PermGen 彻底移除，类的字节码、常量池、字段/方法/接口定义等元数据转存至本地内存的元空间（Metaspace）。它不再属于堆，因此 -Xmx 不控制它，而是用 -XX:MetaspaceSize（初始阈值）和 -XX:MaxMetaspaceSize（上限）约束。
容易踩的坑：
- 动态生成类（如 CGLIB、Spring AOP、某些 ORM 的代理）会持续占用元空间，不设
MaxMetaspaceSize可能导致本地内存耗尽，进程被系统 OOM killer 杀掉 - 元空间 GC 是独立触发的：当达到
MetaspaceSize后，会触发一次 Full GC 尝试卸载无用类（前提是类加载器可被回收），但不会像堆那样频繁回收 -
java.lang.OutOfMemoryError: Metaspace出现时，先检查是否类加载器泄漏（如 Web 应用热部署未清理旧 loader），而不是盲目调大参数
堆、栈、元空间三者边界清晰，但监控和调优必须联动看
比如一个服务频繁 GC，不能只盯着堆的 Old Gen 使用率。如果发现 Metaspace 持续增长且 Full GC 后不下降，大概率是类泄漏；如果线程数飙升伴随 unable to create new native thread，就要查是不是栈太小（-Xss）或线程池没控住；而堆内对象存活时间异常长，可能是因为本该被回收的 Class 对象因类加载器被强引用而滞留——这又牵扯到元空间和 GC 的交互。
真正难的从来不是分清“谁存什么”，而是当 OutOfMemoryError 报出来时，你得从日志、堆转储（jmap -dump）、元空间使用统计（jstat -gc 中的 M 和 MC 列）交叉验证，定位到底是哪一层的资源卡住了。
