news 2026/1/27 14:23:44

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/1/19 4:18:02

HY-MT1.5-7B与Llama3翻译能力对比:中英日韩实战评测

HY-MT1.5-7B与Llama3翻译能力对比:中英日韩实战评测 在大模型驱动的自然语言处理领域,翻译任务正经历从通用理解到专业化、精细化的演进。随着多语言交流需求激增,尤其是在跨境电商、跨国协作和本地化服务场景中,高质量、低延迟的…

作者头像 李华
网站建设 2026/1/18 15:25:21

混元翻译1.5实战:会议实时字幕系统搭建

混元翻译1.5实战:会议实时字幕系统搭建 随着全球化交流的不断深入,多语言会议场景对高质量、低延迟的实时翻译需求日益增长。传统云端翻译服务虽具备较强性能,但在隐私保护、网络依赖和响应延迟方面存在明显短板。腾讯开源的混元翻译大模型 …

作者头像 李华
网站建设 2026/1/25 11:21:33

HY-MT1.5部署疑问解答:网页推理无法连接?实战排查指南

HY-MT1.5部署疑问解答:网页推理无法连接?实战排查指南 1. 背景与问题引入 随着多语言交流需求的不断增长,高质量、低延迟的翻译模型成为智能应用的核心组件。腾讯近期开源了混元翻译大模型 HY-MT1.5 系列,包含两个版本&#xff1…

作者头像 李华
网站建设 2026/1/14 4:55:00

HY-MT1.5-1.8B嵌入式设备部署:低功耗GPU适配实战案例

HY-MT1.5-1.8B嵌入式设备部署:低功耗GPU适配实战案例 随着边缘计算与本地化AI推理需求的快速增长,大模型在资源受限设备上的高效部署成为关键挑战。腾讯开源的混元翻译模型HY-MT1.5系列,特别是其轻量级版本HY-MT1.5-1.8B,凭借出色…

作者头像 李华
网站建设 2026/1/25 4:48:45

HY-MT1.5实时字幕:视频内容翻译方案

HY-MT1.5实时字幕:视频内容翻译方案 随着全球化进程加速,跨语言交流需求激增,尤其是在视频内容传播中,实时、准确的翻译能力成为关键基础设施。腾讯近期开源的混元翻译大模型 HY-MT1.5 系列,凭借其在多语言支持、边缘…

作者头像 李华
网站建设 2026/1/22 18:54:36

HY-MT1.5-7B如何开启上下文翻译?参数设置保姆级教程

HY-MT1.5-7B如何开启上下文翻译?参数设置保姆级教程 随着多语言交流需求的不断增长,高质量、智能化的翻译模型成为跨语言沟通的核心工具。腾讯开源的混元翻译大模型 HY-MT1.5 系列,凭借其在多语言支持、边缘部署能力以及上下文感知翻译方面的…

作者头像 李华