Effective Java 第三版——8. 避免使用Finalizer和Cleaner机制
Tips
《Effective Java, Third Edition》一书英文版已经出版,这本书的第二版想必很多人都读过,号称Java四大名著之一,不过第二版2009年出版,到现在已经将近8年的时间,但随着Java 6,7,8,甚至9的发布,Java语言发生了深刻的变化。
在这里第一时间翻译成中文版。供大家学习分享之用。
8. 避免使用Finalizer和Cleaner机制
Finalizer机制是不可预知的,往往是危险的,而且通常是不必要的。 它们的使用会导致不稳定的行为,糟糕的性能和移植性问题。 Finalizer机制有一些特殊的用途,我们稍后会在这个条目中介绍,但是通常应该避免它们。 从Java 9开始,Finalizer机制已被弃用,但仍被Java类库所使用。 Java 9中 Cleaner机制代替了Finalizer机制。 Cleaner机制不如Finalizer机制那样危险,但仍然是不可预测,运行缓慢并且通常是不必要的。
提醒C++程序员不要把Java中的Finalizer或Cleaner机制当成的C ++析构函数的等价物。 在C++中,析构函数是回收对象相关资源的正常方式,是与构造方法相对应的。 在Java中,当一个对象变得不可达时,垃圾收集器回收与对象相关联的存储空间,不需要开发人员做额外的工作。 C ++析构函数也被用来回收其他非内存资源。 在Java中,try-with-resources或try-finally块用于此目的(条目 9)。
Finalizer和Cleaner机制的一个缺点是不能保证他们能够及时执行[JLS,12.6]。 在一个对象变得无法访问时,到Finalizer和Cleaner机制开始运行时,这期间的时间是任意长的。 这意味着你永远不应该Finalizer和Cleaner机制做任何时间敏感(time-critical)的事情。 例如,依赖于Finalizer和Cleaner机制来关闭文件是严重的错误,因为打开的文件描述符是有限的资源。 如果由于系统迟迟没有运行Finalizer和Cleaner机制而导致许多文件被打开,程序可能会失败,因为它不能再打开文件了。
及时执行Finalizer和 Cleaner机制是垃圾收集算法的一个功能,这种算法在不同的实现中有很大的不同。程序的行为依赖于Finalizer和 Cleaner机制的及时执行,其行为也可能大不不同。 这样的程序完全可以在你测试的JVM上完美运行,然而在你最重要的客户的机器上可能运行就会失败。
延迟终结(finalization)不只是一个理论问题。为一个类提供一个Finalizer机制可以任意拖延它的实例的回收。一位同事调试了一个长时间运行的GUI应用程序,这个应用程序正在被一个OutOfMemoryError错误神秘地死掉。分析显示,在它死亡的时候,应用程序的Finalizer机制队列上有成千上万的图形对象正在等待被终结和回收。不幸的是,Finalizer机制线程的运行优先级低于其他应用程序线程,所以对象被回收的速度低于进入队列的速度。语言规范并不保证哪个线程执行Finalizer机制,因此除了避免使用Finalizer机制之外,没有轻便的方法来防止这类问题。在这方面, Cleaner机制比Finalizer机制要好一些,因为Java类的创建者可以控制自己cleaner机制的线程,但cleaner机制仍然在后台运行,在垃圾回收器的控制下运行,但不能保证及时清理。
Java规范不能保证Finalizer和Cleaner机制能及时运行;它甚至不能能保证它们是否会运行。当一个程序结束后,一些不可达对象上的Finalizer和Cleaner机制仍然没有运行。因此,不应该依赖于Finalizer和Cleaner机制来更新持久化状态。例如,依赖于Finalizer和Cleaner机制来释放对共享资源(如数据库)的持久锁,这是一个使整个分布式系统陷入停滞的好方法。
不要相信System.gc
和System.runFinalization
方法。 他们可能会增加Finalizer和Cleaner机制被执行的几率,但不能保证一定会执行。 曾经声称做出这种保证的两个方法:System.runFinalizersOnExit
和它的孪生兄弟Runtime.runFinalizersOnExit
,包含致命的缺陷,并已被弃用了几十年[ThreadStop]。
Finalizer机制的另一个问题是在执行Finalizer机制过程中,未捕获的异常会被忽略,并且该对象的Finalizer机制也会终止 [JLS, 12.6]。未捕获的异常会使其他对象陷入一种损坏的状态(corrupt state)。如果另一个线程试图使用这样一个损坏的对象,可能会导致任意不确定的行为。通常情况下,未捕获的异常将终止线程并打印堆栈跟踪( stacktrace),但如果发生在Finalizer机制中,则不会发出警告。Cleaner机制没有这个问题,因为使用Cleaner机制的类库可以控制其线程。
使用finalizer和cleaner机制会导致严重的性能损失。 在我的机器上,创建一个简单的AutoCloseable
对象,使用try-with-resources关闭它,并让垃圾回收器回收它的时间大约是12纳秒。 使用finalizer机制,而时间增加到550纳秒。 换句话说,使用finalizer机制创建和销毁对象的速度要慢50倍。 这主要是因为finalizer机制会阻碍有效的垃圾收集。 如果使用它们来清理类的所有实例(在我的机器上的每个实例大约是500纳秒),那么cleaner机制的速度与finalizer机制的速度相当,但是如果仅将它们用作安全网( safety net),则cleaner机制要快得多,如下所述。 在这种环境下,创建,清理和销毁一个对象在我的机器上需要大约66纳秒,这意味着如果你不使用安全网的话,需要支付5倍(而不是50倍)的保险。
finalizer机制有一个严重的安全问题:它们会打开你的类来进行finalizer机制攻击。finalizer机制攻击的想法很简单:如果一个异常是从构造方法或它的序列化中抛出的——readObjec
t和readResolve
方法(第12章)——恶意子类的finalizer机制可以运行在本应该“中途夭折(died on the vine)”的部分构造对象上。finalizer机制可以在静态字属性记录对对象的引用,防止其被垃圾收集。一旦记录了有缺陷的对象,就可以简单地调用该对象上的任意方法,而这些方法本来就不应该允许存在。从构造方法中抛出异常应该足以防止对象出现;而在finalizer机制存在下,则不是。这样的攻击会带来可怕的后果。Final类不受finalizer机制攻击的影响,因为没有人可以编写一个final类的恶意子类。为了保护非final类不受finalizer机制攻击,编写一个final的finalize
方法,它什么都不做。
那么,你应该怎样做呢?为对象封装需要结束的资源(如文件或线程),而不是为该类编写Finalizer和Cleaner机制?让你的类实现AutoCloseable
接口即可,并要求客户在在不再需要时调用每个实例close方法,通常使用try-with-resources确保终止,即使面对有异常抛出情况(条目 9)。一个值得一提的细节是实例必须跟踪是否已经关闭:close方法必须记录在对象里不再有效的属性,其他方法必须检查该属性,如果在对象关闭后调用它们,则抛出IllegalStateException异常。
那么,Finalizer和Cleaner机制有什么好处呢?它们可能有两个合法用途。一个是作为一个安全网(safety net),以防资源的拥有者忽略了它的close
方法。虽然不能保证Finalizer和Cleaner机制会迅速运行(或者根本就没有运行),最好是把资源释放晚点出来,也要好过客户端没有这样做。如果你正在考虑编写这样的安全网Finalizer机制,请仔细考虑一下这样保护是否值得付出对应的代价。一些Java库类,如FileInputStream
、FileOutputStream
、ThreadPoolExecutor
和java.sql.Connection
,都有作为安全网的Finalizer机制。
第二种合理使用Cleaner机制的方法与本地对等类(native peers)有关。本地对等类是一个由普通对象委托的本地(非Java)对象。由于本地对等类不是普通的 Java对象,所以垃圾收集器并不知道它,当它的Java对等对象被回收时,本地对等类也不会回收。假设性能是可以接受的,并且本地对等类没有关键的资源,那么Finalizer和Cleaner机制可能是这项任务的合适的工具。但如果性能是不可接受的,或者本地对等类持有必须迅速回收的资源,那么类应该有一个close
方法,正如前面所述。
Cleaner机制使用起来有点棘手。下面是演示该功能的一个简单的Room
类。假设Room
对象必须在被回收前清理干净。Room
类实现AutoCloseable
接口;它的自动清理安全网使用的是一个Cleaner机制,这仅仅是一个实现细节。与Finalizer机制不同,Cleaner机制不污染一个类的公共API:
// An autocloseable class using a cleaner as a safety net
public class Room implements AutoCloseable {
private static final Cleaner cleaner = Cleaner.create();
// Resource that requires cleaning. Must not refer to Room!
private static class State implements Runnable {
int numJunkPiles; // Number of junk piles in this room
State(int numJunkPiles) {
this.numJunkPiles = numJunkPiles;
}
// Invoked by close method or cleaner
@Override
public void run() {
System.out.println("Cleaning room");
numJunkPiles = 0;
}
}
// The state of this room, shared with our cleanable
private final State state;
// Our cleanable. Cleans the room when it’s eligible for gc
private final Cleaner.Cleanable cleanable;
public Room(int numJunkPiles) {
state = new State(numJunkPiles);
cleanable = cleaner.register(this, state);
}
@Override
public void close() {
cleanable.clean();
}
}
静态内部State
类拥有Cleaner机制清理房间所需的资源。 在这里,它仅仅包含numJunkPiles
属性,它代表混乱房间的数量。 更实际地说,它可能是一个final修饰的long
类型的指向本地对等类的指针。 State
类实现了Runnable
接口,其run
方法最多只能调用一次,只能被我们在Room
构造方法中用Cleaner机制注册State
实例时得到的Cleanable
调用。 对run
方法的调用通过以下两种方法触发:通常,通过调用Room
的close
方法内调用Cleanable
的clean
方法来触发。 如果在Room
实例有资格进行垃圾回收的时候客户端没有调用close
方法,那么Cleaner机制将(希望)调用State
的run
方法。
一个State
实例不引用它的Room
实例是非常重要的。如果它引用了,则创建了一个循环,阻止了Room
实例成为垃圾收集的资格(以及自动清除)。因此,State
必须是静态的嵌内部类,因为非静态内部类包含对其宿主类的实例的引用(条目 24)。同样,使用lambda表达式也是不明智的,因为它们很容易获取对宿主类对象的引用。
就像我们之前说的,Room
的Cleaner机制仅仅被用作一个安全网。如果客户将所有Room
的实例放在try-with-resource块中,则永远不需要自动清理。行为良好的客户端如下所示:
public class Adult {
public static void main(String[] args) {
try (Room myRoom = new Room(7)) {
System.out.println("Goodbye");
}
}
}
正如你所预料的,运行Adult
程序会打印Goodbye
字符串,随后打印Cleaning room
字符串。但是如果时不合规矩的程序,它从来不清理它的房间会是什么样的?
public class Teenager {
public static void main(String[] args) {
new Room(99);
System.out.println("Peace out");
}
}
你可能期望它打印出 Peace out
,然后打印Cleaning room
字符串,但在我的机器上,它从不打印Cleaning room
字符串;仅仅是程序退出了。 这是我们之前谈到的不可预见性。 Cleaner机制的规范说:“System.exit
方法期间的清理行为是特定于实现的。 不保证清理行为是否被调用。”虽然规范没有说明,但对于正常的程序退出也是如此。 在我的机器上,将System.gc()
方法添加到Teenager
类的main
方法足以让程序退出之前打印Cleaning room
,但不能保证在你的机器上会看到相同的行为。
总之,除了作为一个安全网或者终止非关键的本地资源,不要使用Cleaner机制,或者是在Java 9发布之前的finalizers机制。即使是这样,也要当心不确定性和性能影响。
Effective Java 第三版——8. 避免使用Finalizer和Cleaner机制的更多相关文章
- 《Effective Java 第三版》新条目介绍
版权声明:本文为博主原创文章,可以随意转载,不过请加上原文链接. https://blog.csdn.net/u014717036/article/details/80588806前言 从去年的3月份 ...
- 《Effective Java 第三版》目录汇总
经过反复不断的拖延和坚持,所有条目已经翻译完成,供大家分享学习.时间有限,个别地方翻译得比较仓促,希望有疑虑的地方指出批评改正. 第一章简介 忽略 第二章 创建和销毁对象 1. 考虑使用静态工厂方法替 ...
- Effective Java 第三版——1. 考虑使用静态工厂方法替代构造方法
Tips <Effective Java, Third Edition>一书英文版已经出版,这本书的第二版想必很多人都读过,号称Java四大名著之一,不过第二版2009年出版,到现在已经将 ...
- Effective Java 第三版——3. 使用私有构造方法或枚类实现Singleton属性
Tips <Effective Java, Third Edition>一书英文版已经出版,这本书的第二版想必很多人都读过,号称Java四大名著之一,不过第二版2009年出版,到现在已经将 ...
- Effective Java 第三版——7. 消除过期的对象引用
Tips <Effective Java, Third Edition>一书英文版已经出版,这本书的第二版想必很多人都读过,号称Java四大名著之一,不过第二版2009年出版,到现在已经将 ...
- Effective Java 第三版——9. 使用try-with-resources语句替代try-finally语句
Tips <Effective Java, Third Edition>一书英文版已经出版,这本书的第二版想必很多人都读过,号称Java四大名著之一,不过第二版2009年出版,到现在已经将 ...
- Effective Java 第三版——10. 重写equals方法时遵守通用约定
Tips <Effective Java, Third Edition>一书英文版已经出版,这本书的第二版想必很多人都读过,号称Java四大名著之一,不过第二版2009年出版,到现在已经将 ...
- Effective Java 第三版——11. 重写equals方法时同时也要重写hashcode方法
Tips <Effective Java, Third Edition>一书英文版已经出版,这本书的第二版想必很多人都读过,号称Java四大名著之一,不过第二版2009年出版,到现在已经将 ...
- Effective Java 第三版——12. 始终重写 toString 方法
Tips <Effective Java, Third Edition>一书英文版已经出版,这本书的第二版想必很多人都读过,号称Java四大名著之一,不过第二版2009年出版,到现在已经将 ...
随机推荐
- [转载] Quartz作业调度框架
转载自http://yangpanwww.iteye.com/blog/797563 Quartz 是一个开源的作业调度框架,它完全由 Java 写成,并设计用于 J2SE 和 J2EE 应用中.它提 ...
- mysql数据库第二弹
mysql数据库针对表的操作 表记录的增删改查 1.增加一张表 插入记录之前必须得先有表结构! CREATE TABLE score( id int PRIMARY KEY auto_incremen ...
- MySQL运维相关工具汇总(待补充)
1.orztop查看show full processlist http://hidba.org/?p=841 2.orzdba查看系统状态信息 http://code.taobao.org/p/or ...
- jenkins 安装部署 springboot启动
安装稳定版本的jenkins1,前置依赖:安装jdk-1.81,下载yum仓库sudo wget -O /etc/yum.repos.d/jenkins.repo http://pkg.jenki ...
- Celery 源码解析六:Events 的实现
在 Celery 中,除了远程控制之外,还有一个元素可以让我们对分布式中的任务的状态有所掌控,而且从实际意义上来说,这个元素对 Celery 更为重要,这就是在本文中将要说到的 Event. 在 Ce ...
- put()
put() 作用: 将集合的所有键名和值,存放在一个集合对象中. public Map selectSingleData(String sql,Object...obj) throws SQLExc ...
- 工厂模式(Factory Method)
1.工厂方法模式(Factory Method) 工厂方法模式分为三种: 1-1.普通工厂模式,就是建立一个工厂类,对实现了同一接口的一些类进行实例的创建. 举例如下:(我们举一个发送邮件和短信的例子 ...
- JavaScript 性能优化技巧分享
JavaScript 作为当前最为常见的直译式脚本语言,已经广泛应用于 Web 应用开发中.为了提高Web应用的性能,从 JavaScript 的性能优化方向入手,会是一个很好的选择. 本文从加载.上 ...
- ACM HDU 1559 最大子矩阵
题目链接:http://acm.hdu.edu.cn/showproblem.php?pid=1559 这道题 挺好的,当时想出解法的时候已经比较迟了.还是平时看得少. 把行与列都进行压缩.ans[i ...
- 【垃圾回收】Java内存回收实践经验 防止内存报警
jdk6和7服务器端(-server) 默认的新生代的垃圾回收器为:PS Scavenge,老年代默认的垃圾回收器为:PS MarkSweep 目前项目使用了jdk7,tomcat7,经常出现内存堆使 ...