Java 中对象的内存分配过程是怎样的？对象分配在堆还是栈？

# 一句话结论 * **语言规范不规定分配位置**；HotSpot 的**默认**做法是：**绝大多数新对象分配在堆（新生代 Eden）**，由 GC 管理。 * **但**：JIT 通过**逃逸分析**可把一部分对象**消解为标量（俗称“栈上分配”）**，甚至**直接消除分配**；因此**有些对象根本不会进入堆**。 # 对象分配的标准路径（HotSpot） 1. **`new` 字节码**：检查类已加载/初始化（首次用到时触发 `<clinit>`）。 2. **选择分配缓冲区** * **优先 TLAB（Thread-Local Allocation Buffer）**：每线程一小块 Eden，走“**指针碰撞**”快速分配；TLAB不够→ refill；关闭 TLAB 则走公共 Eden。 3. **Eden 不足 → 慢路径** * 触发 **Minor GC** 回收新生代；仍不足则尝试**老年代晋升**，再不行抛 `OutOfMemoryError: Java heap space`。 4. **初始化** * **零初始化**对象内存； * 填写**对象头**（Mark Word：锁状态/哈希/年龄；Klass 指针：类元数据引用）； * 调用构造器 `<init>` 设定字段初值； * 返回对象引用。 5. **存活与晋升** * Minor GC 后存活对象从 Eden→Survivor（S0/S1），年龄达阈值或 Survivor 放不下则**晋升老年代**。 # 什么时候“不是堆” > 严格说，HotSpot 主流做法是**标量替换**，没有真正构造一个带对象头的“栈对象”；但工程里常把它口语化称为“栈上分配”。 * **逃逸分析（Escape Analysis）**：若对象**不逃出当前方法/线程**（不赋给全局、不会返回、不会放到可能跨线程的数据结构），JIT 可能： * **标量替换**：把对象的字段拆成若干局部变量/寄存器 → **根本不分配内存**； * **栈上分配（等价效果）**：对象生命周期受限于当前栈帧，方法返回即回收； * **同步消除**：对象锁只在本线程可见，去掉无意义的 `synchronized`。 * 相关开关（通常默认开启）：`-XX:+DoEscapeAnalysis`、`-XX:+EliminateAllocations`。 * 注意：**JIT 才会发生**，解释执行或某些复杂控制流下可能**不触发**这些优化。 # 大对象与特殊路径 * **很大的数组/对象**：某些收集器会让其**直接进老年代/大对象区**（如 G1 的 Humongous Region），避免反复在新生代复制。 * **直接内存（堆外）**：`ByteBuffer.allocateDirect` 等会向本地内存申请数据区；**Java 对象壳在堆上**，但真实缓冲在堆外（受 `-XX:MaxDirectMemorySize` 约束）。 # 堆 vs 栈的判断范式 * **默认认为：对象在堆**； * **若代码局部、短命、无逃逸** → 大概率被 JIT **优化掉分配**（你在 GC 日志里看不到它）； * **只要对象需要跨方法/线程存在或被返回/共享** → 必在**堆**（由 GC 管理）。 # 小例子（理解逃逸与分配） ```java // 可能被标量替换：不逃逸 int f() { Point p = new Point(1, 2); // JIT 可能把x=1,y=2拆成两个局部，不分配对象 return p.x + p.y; } // 必然在堆：逃逸到返回值 Point g() { return new Point(1, 2); // 对象作为返回值逃逸 → 在堆上分配 } ``` # 相关调优与观察 * **TLAB**：默认启用，极大降低分配锁竞争；`-XX:-UseTLAB` 可关（一般没必要）。 * **观察是否发生对象分配/逃逸**： * GC 日志看分配速率与晋升； * JIT 日志/`jitwatch` 等可分析标量替换（诊断开关因版本而异）。 * **热点现象**：热点短命对象（如临时 `StringBuilder`）多数在 Eden 快速分配并很快被 Minor GC 清理；若逃逸被消除，更是直接“零代价”。 # 一张口吻化的总结 * **日常写的 `new`** → **默认在堆（Eden/TLAB）**； * **JIT 够聪明时** → **把一部分“看起来要分配”的对象优化成不分配/等效栈生命期**； * **跨方法/线程/共享** → **一定在堆**； * **NIO 大缓存** → **数据在堆外**，但“壳”仍在堆。