Java对象生命周期解析：创建与销毁全过程

Java对象的生命周期远不止“new”和“GC回收”两个简单动作：从类加载验证、内存分配与初始化，到构造函数执行；从GC Roots可达性判定存活，到弱引用/软引用的灵活管理；再到finalize的彻底弃用与Cleaner或try-with-resources的确定性资源清理——整个过程充满隐式规则与潜在陷阱。尤其值得注意的是，对象既没有明确的销毁时刻，也不提供可靠的析构回调，真正危险的往往不是创建与回收本身，而是中间那段“无人值守”的引用生命周期——稍有不慎，就会引发内存泄漏、资源耗尽或Full GC风暴。理解这些底层机制，才能写出健壮、高效、可维护的Java代码。

对象创建时发生了什么

Java对象的生命周期从new指令开始，但实际远不止分配内存那么简单。JVM会先检查类是否已加载、解析和初始化；接着在堆上为对象分配内存（可能触发GC），再将内存清零（保证字段默认值）；最后执行方法——也就是你写的构造函数。

• new后立刻调用构造函数，哪怕没显式写super()，编译器也会自动插入
• 构造函数里若调用this(...)或super(...)，必须是第一行语句，否则编译报错call to this/super must be first statement
• 如果类有静态字段或静态代码块，它们只在类首次主动使用时执行一次，与对象创建无关

对象什么时候算“存活”

JVM判断对象是否存活，不看有没有变量引用它，而是看能否从GC Roots（如栈帧中的局部变量、静态字段、JNI引用等）出发，通过引用链到达该对象。只要可达，就视为“存活”，不会被回收。

• 局部变量引用的对象，在方法退出后若无其他强引用，立即变成不可达
• 静态集合（如static List）长期持有对象引用，容易造成内存泄漏
• 使用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连接）。

• JVM不提供对象销毁通知机制，finalization已被弃用，Cleaner也仅用于异步清理，不保证顺序或及时性
• 真正需要确定性清理的资源，必须手动调用close()、dispose()等方法，或用try-finally/try-with-resources
• 对象进入老年代后，回收成本更高，频繁创建短命大对象（如大数组）会加速晋升，引发Full GC

对象生命周期里最易被忽略的，是“创建”和“销毁”之间那一大段无人值守的时间——引用关系怎么维护、谁持有谁、什么时候该断开，这些细节比构造函数和GC算法本身更容易导致问题。

终于介绍完啦！小伙伴们，这篇关于《Java对象生命周期解析：创建与销毁全过程》的介绍应该让你收获多多了吧！欢迎大家收藏或分享给更多需要学习的朋友吧~golang学习网公众号也会发布文章相关知识，快来关注吧！