在与主题直接合作或花时间学习它们之后，我经常会发现自己在网上注意到更多主题。 最近的Stephen Connolly （ CloudBees ）发表FileInputStream / FileOutputStream被认为有害的消息引起了我的注意，因为我最近在Java的finalizer中遇到了问题 。 在那篇文章中 ，作者讨论了实现重写的finalize（）方法FileInputStream.finalize（）和FileOutputStream.finalize（）的java.io.FileInputStream和java.io.FileOutputStream的潜在后果。 谈论过不赞成使用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