news 2026/7/17 14:55:02

JVM-finalize()方法

作者头像

张小明

前端开发工程师

1.2k 24
文章封面图
JVM-finalize()方法

Finalize方法不被推荐使用原因

该函数允许在子类中被重写,用于在对象被回收时进行资源地释放。目前,普遍的认识是,尽量不要使用finalize()函数进行资源释放,原因主要有以下几点:

1、在finalize()时可能会导致对象复活;

2、finalize()函数的执行时间是没有保障的,它完全由GC线程决定,极端情况下,若不发生GC,则finalize()将没有机会执行;

3、一个糟糕的 finalize()会严重影响GC的性能;

函数finalize()是由FinalizerThread 线程处理的。正式回收对象前,这类对象会被封装为Finalizer引用对象(本质是引用类型),并被加入ReferenceQueue引用队列(内部是链表结构),由该队列调度FinalizerThread执行其finalize()方法。

Finalizer内部封装了实际的回收对象,如图所示。可以看到next、prev 为实现链表所需

,它们分别指向队列中的下一个元素和上一个元素。

finalizee是要回收的对象,比如,在后续的示例中就为LongFinalize$LF。

由于对象在回收前被Finalizer 的referent 字段进行“强引用”,并加入了FinalizerThread的执行队列,这意味着对象又变为可达对象,因此阻止了对象的正常回收。由于在引用队列中的元素排队执行finalize()方法,一旦出现性能问题,将导致这些垃圾对象长时间堆积在内存中,可能会导致OOM异常。

-Xmx10m -Xms10m -XX:+PrintGCDetails -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath="D:/f.dump"

使用上述参数进行堆内存溢出的dump文件下载,并使用Mat进行文件分析:

从最大对象中可以看到,目前系统中有大量的Finalizer类,这意味着FinalizerThread 执行

列可能一直持有对象而来不及执行,因此大量的对象堆积而无法被释放,最终导致了这个OOM。

去掉LF类的finalize()方法,再次以相同的参数运行这段程序。可以观察到,程序很快正常结束。由此,|可以进一步说明finalize()对GC产生的影响。

注意:一个糟糕的finalize()可能会使对象长时间被Finalizer 引用,而得不到释放,因

此这会进一步增加GC的压力。因此,finalize()应该是尽量少 地被使用。

Finalizer方法重写导致OOM原因

@Override protected void finalize() { try { System.out.println(Thread.currentThread().getId()); Thread.sleep(1000); } catch (Exception e) { e.printStackTrace(); } }

核心逻辑finalize()会让对象的 “回收流程变复杂 + 延迟”。

finalize()Object类的一个方法,原本设计是让对象在被垃圾回收前做最后一次资源清理,但它的执行机制会改变对象的 “可回收状态”。

重写与不重写的区别

当你不重写finalize()时:

1、循环里创建的LF对象是普通强引用对象,循环结束后,这些对象没有任何引用(f是局部变量,每次循环后就失效了)。

2、GC 可以直接识别这些 “无引用的对象”,将其回收,内存会被循环利用,所以不会触发 OOM。

重写finalize()的情况:对象被 “延迟回收”,最终堆积导致 OOM:

当你重写finalize()后,JVM 会给这类对象加一层 “特殊处理”:

1、包装为 Finalizer 引用

每个LF对象创建后,JVM 会把它包装成java.lang.ref.Finalizer对象Finalizer是一种特殊的引用类型,属于 JVM 内部维护的引用)

2、对象暂时 “变可达”

Finalizer对象会被加入 JVM 的Finalizer队列(一个链表结构),此时LF对象因为被Finalizer引用,会从“无引用状态”变成“可达状态”——GC 认为它还有引用,不能立即回收

3、FinalizerThread 处理缓慢,对象堆积

JVM 会启动一个低优先级线程FinalizerThread,负责遍历Finalizer队列、执行每个Finalizer对应的finalize()方法。

但你在finalize()里加了Thread.sleep(1000),导致FinalizerThread处理每个对象要等 1 秒 —— 而你循环每秒能创建大量LF对象,处理速度远赶不上创建速度

最终结果:大量LF对象被Finalizer持有、无法回收,内存被占满,触发 OOM。

finalize()到底是干啥的?为什么“过时”了

它原本的设计是 “让对象在回收前做资源清理”,但因为:

1、执行依赖低优先级的FinalizerThread,可能迟迟不执行;

2、会延迟对象回收,甚至会导致 OOM;

3、执行结果不可控;

所以finalize()已经被 JDK 标记为过时方法(@Deprecated),现在完全不推荐使用。

版权声明: 本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若内容造成侵权/违法违规/事实不符,请联系邮箱:809451989@qq.com进行投诉反馈,一经查实,立即删除!
网站建设 2026/7/1 13:19:22

HY-MT1.5-7B性能调优:批处理大小最佳实践

HY-MT1.5-7B性能调优:批处理大小最佳实践 1. 背景与问题引入 随着多语言交流需求的不断增长,高质量、低延迟的机器翻译系统成为智能应用的核心组件。腾讯开源的混元翻译大模型 HY-MT1.5 系列,凭借其在多语言互译、混合语言理解与格式化输出…

作者头像 李华
网站建设 2026/7/1 17:06:47

PyTorch FSDP分布式训练加速实战

💓 博客主页:借口的CSDN主页 ⏩ 文章专栏:《热点资讯》 PyTorch FSDP分布式训练加速:实战指南与前沿洞察目录PyTorch FSDP分布式训练加速:实战指南与前沿洞察 引言:分布式训练的瓶颈与FSDP的崛起 一、技术应…

作者头像 李华
网站建设 2026/7/15 1:13:28

伪代码展示波形改善

基于线性死区补偿的PMSM矢量控制算法仿真,Foc电流双闭环 1.模块划分清晰,易于学习; 2.死区补偿算法的线性区区域可调; 3.自己总结的死区补偿算法笔记及精华资料; 4.完全自己手动搭建在PMSM矢量控制系统中,死区效应就像电路板上的隐形刺客——…

作者头像 李华
网站建设 2026/7/15 1:13:00

混元翻译1.5模型测试:自动化评估方案

混元翻译1.5模型测试:自动化评估方案 近年来,随着多语言交流需求的激增,高质量机器翻译模型成为跨语言沟通的核心基础设施。腾讯推出的混元翻译大模型(HY-MT)系列持续迭代,最新发布的 HY-MT1.5 版本在翻译…

作者头像 李华
网站建设 2026/7/15 1:15:32

混元翻译1.5格式化翻译:结构化文本处理指南

混元翻译1.5格式化翻译:结构化文本处理指南 1. 引言:混元翻译模型的演进与定位 随着全球化进程加速,高质量、多语言互译能力已成为自然语言处理(NLP)领域的重要基础设施。在这一背景下,腾讯推出了开源翻译…

作者头像 李华
网站建设 2026/7/16 7:45:05

腾讯Hunyuan模型部署难?镜像开箱即用教程来解答

腾讯Hunyuan模型部署难?镜像开箱即用教程来解答 1. 引言:从开源翻译模型到开箱即用的实践突破 随着大模型在自然语言处理领域的持续演进,高质量、低延迟的机器翻译需求日益增长。腾讯推出的 HY-MT1.5 系列翻译模型,作为其 Hunyua…

作者头像 李华