Java堆栈内存分配详解

Java中局部变量和方法调用帧（含基本类型和对象引用）存于栈，对象实例、数组及所有new创建的对象存于堆；String字面量在常量池（属堆），new String()在堆新建对象。

Java中哪些变量存在栈上，哪些在堆上

Java的栈内存只存局部变量和方法调用帧，包括基本类型（int、boolean等）和对象引用（String s中的s本身），但不存对象实体；对象实例（如new String("abc")产生的字符串对象）、数组、所有通过new创建的实例，都分配在堆内存中。

常见误解是“String在栈上”，其实String s = "hello"中，s这个引用在栈，而"hello"字面量在运行时常量池（属于堆的一部分，JDK 7+后已移入堆），new String("hello")则明确在堆上新建两个对象（一个在常量池，一个在堆）。

• 方法参数如果是基本类型，值拷贝进栈；如果是引用类型，引用（即地址）拷贝进栈，对象仍在堆
• 静态变量（static字段）和类元数据（Class对象、方法区信息）不在栈或堆，而是放在元空间（Metaspace，JDK 8+）或永久代（JDK 7及以前）
• 局部变量若被内部类或lambda捕获，可能被编译器提升为堆对象（逃逸分析后可能优化回栈，但不可依赖）

逃逸分析如何影响栈上分配

HotSpot JVM在JDK 6u23后默认开启逃逸分析（-XX:+DoEscapeAnalysis），它会判断一个新对象是否“逃逸”出当前方法或线程作用域。如果没逃逸（例如只在方法内使用、未被返回、未被赋给静态字段、未被传入未知方法），JVM可能将该对象直接分配在栈上（标量替换），避免堆分配和GC压力。

但这不是开发者能显式控制的：没有stackalloc关键字，也不能强制指定。你只能通过写法间接影响，比如：

• 避免将局部对象返回（return new ArrayList<>() → 逃逸）
• 避免赋值给static或成员变量
• 避免作为参数传递给可能存储引用的方法（如someMap.put(key, obj)）
• 注意日志框架（如SLF4J）的logger.debug("msg", obj)可能触发逃逸（取决于实现）

用-XX:+PrintEscapeAnalysis可查看分析结果，但实际是否栈分配还受JIT编译时机、对象大小、同步块等限制——小对象更可能被优化，带锁或复杂字段的对象基本不会。

堆内存分配失败时抛什么异常

堆空间不足时，JVM会先尝试GC；若GC后仍无法满足分配需求，抛出java.lang.OutOfMemoryError: Java heap space。这不是Exception，不能被常规catch捕获（除非用catch (Throwable)，但极不推荐）。

要注意区分其他OOM类型：

• OutOfMemoryError: Metaspace → 类加载过多，需调-XX:MaxMetaspaceSize
• OutOfMemoryError: GC overhead limit exceeded → GC花太多时间却回收太少，通常意味着堆太小或有内存泄漏
• OutOfMemoryError: unable to create new native thread → 栈空间耗尽（每个线程默认1MB栈），和堆无关

排查时优先看GC日志（加-Xlog:gc*）和堆转储（-XX:+HeapDumpOnOutOfMemoryError），而不是盲目加大-Xmx。

String、Integer等包装类的内存行为特殊在哪

它们的“缓存机制”直接影响堆/栈分配行为，容易误判内存位置：

• Integer i = 127 → 使用Integer.valueOf(127)，命中缓存（-128~127），返回常量池中已有对象，不新建堆对象
• Integer i = 128 → 缓存未命中，每次调用valueOf都新建堆对象（除非手动缓存）
• String s = "abc" → 字符串字面量，指向字符串常量池（堆内），重复字面量复用同一对象
• String s = new String("abc") → 强制在堆上新建对象，即使常量池已有

这种复用看似节省内存，但也会导致意外的引用相等（==成立），尤其在序列化、深拷贝、多线程共享时容易出错。别依赖缓存做逻辑判断，一律用.equals()。

真正难调试的，是逃逸分析失效叠加缓存复用——比如一个本该栈分配的小对象，因被ConcurrentHashMap缓存而长期驻留堆中，又没明显引用链，GC Roots追踪就容易漏掉。