免费网络咨询免费建站,菠菜网站开发一条龙,百度文库个人登录入口,重庆网站制作珠海公司在与主题直接合作或花时间学习它们之后#xff0c;我经常会发现自己在网上注意到更多主题。 最近的Stephen Connolly #xff08; CloudBees #xff09;发表FileInputStream / FileOutputStream被认为有害的消息引起了我的注意#xff0c;因为我最近在Java的finalizer中遇… 在与主题直接合作或花时间学习它们之后我经常会发现自己在网上注意到更多主题。 最近的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