finalizer_Java Finalizer和Java文件输入/输出流

finalizer

在与主题直接合作或花时间学习它们之后，我经常会发现自己在网上注意到更多主题。 最近的Stephen Connolly （ CloudBees ）发表了FileInputStream / FileOutputStream被认为有害的文章，引起了我的注意，因为我最近遇到了Java终结器的 问题 。 在那篇文章中 ，作者讨论了java.io.FileInputStream和java.io.FileOutputStream实现覆盖的finalize（）方法FileInputStream.finalize（）和FileOutputStream.finalize（）的潜在后果。 谈到弃用JDK 9中的终结器 ，我的观点是，多年来我一直未曾想到的一个主题突然在我身边。

Connolly的帖子引用了Hadoop JIRA HDFS-8562 （“ HDFS性能受FileInputStream Finalizer影响”）。 该JIRA于2015年6月开放，其描述包括有趣的背景，说明FileInputStream的终结器为何会导致使用HDFS的用户FileInputStream问题。 这个JIRA也很有趣，因为它说明了为什么不更改FileInputStream和FileOutputStream而不使用protected finalize()方法并不容易。

HDFS-8562中引用了JDK-8080225 （“ FileInputStream清理应该加以改进。”），它于2015年5月编写。它指出：“如果尚未关闭FIS，则FileInputStream依赖于终结处理来执行最终关闭。 这会导致发生突发的GC的额外工作。 FileInputStreams的清理应尽早进行，并且不会增加GC的开销。” 艾伦·贝特曼（Alan Bateman）通过变通办法对此进行了评论，“通过使用Files.newInputStream可以轻松解决此问题。” 罗杰·里格斯（Roger Riggs）写道，要充分解决这个问题是很困难的，“由于未知/未知，有多少FIS / FOS子类可能依赖于重写或最终确定兼容性问题，这一点非常严重。 只有长期（多次发布）限制以弃用或使覆盖无效，才有可能最终消除兼容性问题。”

Connolly在文章结尾引用了Jenkins通过JENKINS-42934进行的更改 （“避免使用新的FileInputStream /新的FileOutputStream”）。 在那里提供了将new FileInputStream更改为Files.newInputStream的示例。

即使使用了FileInputStream类的类，我已经能够使用Java多年而不必担心终结器了，这一事实证明，就其本身而言，这些类与finalize()实现的有限使用并不一定会导致垃圾收集或其他问题。 我喜欢Colin P. McCabe在HDFS JIRA中阐明此问题的方式：“虽然确实在许多地方都使用FileInputStream / FileOutputStream，但这些地方中的大多数都有短暂的对象或仅使用很少的对象。 就像我之前提到的，终结器遇到的最大问题是短路读取流缓存。 如果我们能够解决此补丁程序试图解决的问题，那么我们将解决大多数问题。” 换句话说，并非所有对FileInputStream和FileOutputStream都引起关注。 使用工具识别与终结器相关的异常高的垃圾收集是识别需要解决的垃圾的最佳方法。

多年来的Java开发，我都没有使用过Java终结器。 近几个月来，这已经成为一个问题，我看到越来越多的人正在处理。 淘汰Java终结器是将其从核心API中删除的一个很好的第一步。

翻译自: https://www.javacodegeeks.com/2017/04/java-finalizer-java-file-inputoutput-streams.html

finalizer