普通java对象生命周期由jvm五大内存区域协同管理：诞生于堆（eden区为主），由虚拟机栈帧触发并持有引用；存活依赖gc roots可达性（根源于栈、方法区等）；消亡时堆中回收对象，方法区清理类元数据；tlab和栈上分配属优化例外。
普通Java对象的生命周期，本质上是由JVM五大内存分区协同管理的结果——不是单靠“堆”就能说清，而是从创建、使用到消亡，每一步都落在特定区域上。理清这个过程，关键在于把对象的“出生地”“成长路径”“归宿去向”和“退出机制”对应到五大分区的功能逻辑里。
对象诞生：在堆中分配，但由栈帧触发
当你写 new Person()，真正执行分配动作的是堆（Heap），但触发这一动作的，是当前线程的虚拟机栈中正在运行的方法所对应的栈帧。栈帧里的局部变量表会保存这个对象的引用（比如 Person p = new Person(); 中的 p），而对象本体（包括字段值、数组元素等）一定落在堆中。
- 绝大多数对象直接在新生代 Eden 区分配
- 若 Eden 空间不足，会触发 Minor GC；存活对象进入 Survivor 区，多次幸存后晋升至老年代
- 大对象（如大数组）可能被直接分配到老年代，避免频繁复制
对象存活：依赖引用关系，受GC根可达性约束
对象是否“活着”，不取决于它在堆里占着位置，而取决于是否存在一条从GC Roots（如虚拟机栈中的局部变量、静态变量、本地方法栈中的引用等）出发、能到达它的引用链。只要这条链存在，对象就在堆中继续驻留。
- GC Roots 主要来自：虚拟机栈（栈帧中的局部变量）、方法区（静态字段）、本地方法栈（JNI引用）、运行时常量池中的字符串常量等
- 程序计数器、虚拟机栈、本地方法栈本身不存对象，但它们持有的引用，是判断堆中对象能否被回收的关键依据
对象消亡：堆内回收 + 方法区联动清理
当对象不再被任何GC Roots可达时，它成为垃圾，等待被回收。但真正的“生命周期终结”还涉及配套元信息的清理：
- 堆中对象空间由垃圾收集器（如G1、ZGC）回收，释放内存供新对象复用
- 若该对象所属的类已无实例且被卸载，其类元数据（类名、方法字节码、常量池等）原本存于方法区（JDK 8+为元空间），也会被清理
- 元空间位于本地内存，不受堆GC影响，但类卸载需满足严格条件（如加载该类的ClassLoader已被回收）
特殊路径：TLAB加速分配 & 栈上分配例外
虽然规范规定对象在堆分配，但JVM做了两项优化，让部分对象“看似绕开堆”：
- TLAB（Thread Local Allocation Buffer）：每个线程在Eden区预划一小块私有缓冲区，对象在其内快速分配，无需同步，仍属堆内存范畴
- 逃逸分析支持下的栈上分配：若JVM判定某对象不会逃逸出当前方法作用域（即无外部引用、不被返回、不被存储到全局变量），可将其字段直接分配在栈帧中，随方法结束自动销毁——这属于优化手段，不改变对象生命周期本质逻辑
不复杂但容易忽略：对象生命周期不是孤立事件，它是五大分区职责分工与协作的具象体现。堆管存，栈管引，计数器定执行点，方法区管类型定义，GC机制贯穿始终。抓住这个分工脉络，就抓住了Java内存管理的主干。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
