企业网站最重要的访问对象是,航达建设集团有限公司网站,网站demo怎么做,阿里OSS做网站图库费用finalizer在与主题直接合作或花时间学习它们之后#xff0c;我经常会发现自己在网上注意到更多主题。 最近的Stephen Connolly #xff08; CloudBees #xff09;发表了FileInputStream / FileOutputStream被认为有害的文章#xff0c;引起了我的注意#xff0c;因为我最… 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.htmlfinalizer
