Java对象在执行new指令时创建，经历类加载检查、内存分配、零值初始化、设置对象头、执行构造方法；若构造中抛异常则对象“半途夭折”，无引用且不被GC回收。
对象什么时候被创建出来
Java对象在执行 new 指令时才真正诞生，这个过程包括：类加载检查 → 分配内存（堆中）→ 初始化零值 → 设置对象头 → 执行 new 不等于“立即可用”——如果构造函数里抛出异常（比如 NullPointerException 或自定义异常），对象虽已分配内存，但不会完成初始化，也不会被赋值给任何变量，此时它算“半途夭折”，GC 通常不会介入，因为根本没引用指向它。
常见误判：以为 String s = "hello" 创建了新对象——其实这是字符串常量池的引用，不走 new 流程；而 new String("hello") 才会额外在堆上新建一个对象（即使内容相同）。
对象什么时候算“活着”
一个对象是否“活着”，只看它是否能被 GC Roots（如栈帧中的局部变量、静态字段、JNI 引用等）**可达**。只要有一条引用链能走到它，它就处于“强可达”状态，不会被回收。
-
final字段赋值后不可变，但不影响对象本身的可达性判断 - 局部变量超出作用域（比如方法 return 后），若无其他引用保留，对象立刻变为“不可达”
- 使用
WeakReference或SoftReference持有对象时，它可能在 GC 时被回收，不算“强存活”
对象怎么被回收
GC 并不是一发现不可达就立刻清理。JVM 会先标记对象为“可回收”，再根据垃圾收集器策略决定何时真正释放内存。不同 GC 算法行为差异很大：
立即学习“Java免费学习笔记（深入）”；
-
Serial/Parallel：只在 STW（Stop-The-World）阶段回收，对象死亡后内存被整体整理或复制 -
G1：按 Region 回收，对象死亡后其所在 Region 可能在下次 GC 周期被清理 -
ZGC/Shenandoah：并发标记 + 并发回收，对象死亡后内存可能延迟数个周期才真正归还给堆管理器
特别注意：finalize() 方法已被废弃（自 Java 9 起标记为 @Deprecated），且不保证执行、不保证及时、不保证只执行一次——绝不能用来释放资源（如文件句柄、数据库连接），必须用 try-with-resources 或显式 close()。
对象销毁后还有痕迹吗
内存被回收后，对象本身彻底消失，但某些痕迹可能残留：
- JVM 参数
-XX:+PrintGCDetails会输出每次 GC 中回收的对象大小统计，但不记录具体对象身份 - 如果启用了 JFR（Java Flight Recorder）并配置了对象分配事件，可以追溯某类对象的分配热点，但无法查“某个特定对象”何时消亡
- 使用
java.lang.ref.PhantomReference可以在对象被回收后收到通知，但此时对象内存已释放，只能做日志或清理关联外部资源（如 off-heap 内存）
别指望通过堆 dump 查“刚死的对象”——jmap -dump 抓的是某一时刻的快照，里面只有仍存活的对象；已回收的不会出现，也不会留下 ID 或痕迹。
