Java对象创建时JVM先检查类状态，再分配并清零内存，最后执行构造函数；对象存活取决于GC Roots可达性；销毁无明确时刻，依赖GC回收，finalize已弃用，应手动管理资源。
对象创建时发生了什么
Java对象的生命周期从new指令开始，但实际远不止分配内存那么简单。JVM会先检查类是否已加载、解析和初始化；接着在堆上为对象分配内存（可能触发GC），再将内存清零（保证字段默认值）；最后执行<init></init>方法——也就是你写的构造函数。
-
new后立刻调用构造函数，哪怕没显式写super()，编译器也会自动插入 - 构造函数里若调用
this(...)或super(...)，必须是第一行语句，否则编译报错call to this/super must be first statement - 如果类有静态字段或静态代码块，它们只在类首次主动使用时执行一次，与对象创建无关
对象什么时候算“存活”
JVM判断对象是否存活，不看有没有变量引用它，而是看能否从GC Roots（如栈帧中的局部变量、静态字段、JNI引用等）出发，通过引用链到达该对象。只要可达，就视为“存活”，不会被回收。
- 局部变量引用的对象，在方法退出后若无其他强引用，立即变成不可达
- 静态集合（如
static List<object> cache</object>）长期持有对象引用，容易造成内存泄漏 - 使用
WeakReference或SoftReference可让对象在GC时更早被回收，适合缓存场景
finalize()不是析构函数，别依赖它
finalize()方法在对象被判定为不可达、且尚未被回收前，由JVM的Finalizer线程调用一次。但它不保证何时执行、甚至不保证一定执行——JVM退出时可能直接忽略所有待回收对象的finalize()。
- JDK 9起已标记
@Deprecated，JDK 18中彻底移除（可通过--enable-preview --add-modules jdk.unsupported临时启用，但不推荐） - 替代方案是使用
Cleaner（JDK 9+）或显式资源管理（try-with-resources） - 若重写了
finalize()，对象会被放入F-Queue队列，延迟回收，增加GC压力
对象真正销毁的那一刻
对象销毁没有“那一刻”。它只是在某次GC过程中，被标记为可回收，随后内存被回收器（如G1、ZGC）清理并归还给堆空间。这个过程不触发任何用户可控的回调，也不释放本地资源（如文件句柄、Socket连接）。
立即学习“Java免费学习笔记（深入）”；
- JVM不提供对象销毁通知机制，
finalization已被弃用，Cleaner也仅用于异步清理，不保证顺序或及时性 - 真正需要确定性清理的资源，必须手动调用
close()、dispose()等方法，或用try-finally/try-with-resources - 对象进入老年代后，回收成本更高，频繁创建短命大对象（如大数组）会加速晋升，引发Full GC
对象生命周期里最易被忽略的，是“创建”和“销毁”之间那一大段无人值守的时间——引用关系怎么维护、谁持有谁、什么时候该断开，这些细节比构造函数和GC算法本身更容易导致问题。
