Java中栈存局部变量和方法调用信息，堆存所有new对象；字符串常量池JDK7+起位于堆中；逃逸分析理论上可栈上分配对象但实际极少生效。
栈内存只存局部变量和方法调用信息
Java 中的栈（Stack）是线程私有的，每个线程启动时都会分配一块独立的栈空间。它只保存方法执行过程中的 基本类型变量（如 int、boolean）、对象引用（即指向堆中对象的指针），以及方法调用的 栈帧（含局部变量表、操作数栈、动态链接等）。
常见误解是“栈里存对象”，其实不是：哪怕写 String s = new String("abc");，s 这个引用在栈上，而 "abc" 对象本身一定在堆里。
栈的特点是自动管理：方法入栈 → 分配空间；方法返回 → 整个栈帧弹出，无需 GC 干预。一旦栈深度超限（比如无限递归），会抛出 StackOverflowError。
堆内存存放所有 new 出来的对象实例
堆（Heap）是 JVM 中最大的一块内存区域，被所有线程共享。所有通过 new 关键字、反射、克隆等方式创建的对象实例，都分配在堆上——包括数组、包装类（Integer、Boolean）、集合容器（ArrayList、HashMap）里的元素对象。
立即学习“Java免费学习笔记（深入）”；
堆由垃圾收集器（GC）统一管理，对象是否存活、何时回收，全看 GC 算法（如 G1、ZGC）。如果堆空间不足且无法扩展，会抛出 OutOfMemoryError: Java heap space。
注意：堆里也存部分元数据，比如对象头（mark word、klass pointer）、对齐填充，但这些对应用层透明；真正需要你关心的是——只要用了 new，就默认在堆里。
字符串常量池在 JDK 7+ 后移到堆中
早期 JDK（6 及以前），字符串常量池（StringTable）位于永久代（PermGen），属于方法区的一部分；JDK 7 开始，它被移到堆内存中；JDK 8 彻底移除永久代，改用元空间（Metaspace），而字符串常量池仍保留在堆里。
这意味着：String s = "hello"; 创建的字面量字符串，现在也是堆对象。虽然它有特殊缓存机制（intern()），但它和其他堆对象一样受 GC 管理——当没有强引用且发生 Full GC 时，未被 intern() 的字符串可能被回收。
验证方式：运行时加参数 -XX:+PrintStringTableStatistics 可查看常量池大小与占用情况。
逃逸分析可能让对象分配在栈上（但实际极少生效）
JVM 的逃逸分析（Escape Analysis）是一种 JIT 优化技术，理论上可判断一个对象是否“逃逸”出当前方法或线程。若确认未逃逸（例如仅作为局部变量使用、未被传入其他方法、未被写入堆中对象字段），JIT 编译器可能将其分配在栈上（标量替换），从而避免 GC 压力。
但现实中几乎看不到效果，原因包括：
- JDK 8 默认开启逃逸分析，但必须配合分层编译（
-XX:+TieredStopAtLevel=1会禁用） - 大多数业务代码存在隐式逃逸：日志打印、异常构造、集合 add、Lambda 捕获等都会让对象逃逸
- HotSpot 在 JDK 15 后已废弃该优化路径，GraalVM 等替代方案也不主推栈上分配
所以，别依赖逃逸分析来“把对象放栈上”，它不构成稳定行为，也不该进入你的设计逻辑。
真正要盯住的，是堆内存增长是否异常、GC 频次是否陡增、栈深度是否接近极限——这些才是影响线上服务稳定性的硬指标。栈和堆的边界在 JVM 规范里写得清楚，但具体到一次 OOM 是谁的锅，得靠 jstat、jmap、堆转储分析来定位，不能光靠概念区分。
