jdk8读取文件_JDK 7和JDK 8中大行读取速度较慢的原因

jdk8读取文件

我早些时候发布了博客文章Reading Large Lines Slower in JDK 7和JDK 8，并且在描述该问题的文章上有一些有用的评论。这篇文章提供了更多解释，说明为何该文章中演示的文件读取（并由Ant的LineContainsRegExp使用）在Java 7和Java 8中比在Java 6中这么慢。

X Wang的帖子JDK 6和JDK 7中的substring（）方法描述了如何在JDK 6和JDK 7之间更改String.substring（）。Wang在该帖子中写道，JDK 6 substring() “创建了一个新字符串，但字符串的值仍指向堆中相同的[backing char]数组。” 他与JDK 7方法形成对比，“在JDK 7中，substring（）方法实际上在堆中创建了一个新数组。”

Wang的帖子对于理解Java 6和Java 7之间String.substring()的区别非常有用。对该帖子的评论也很有见地。这些评论包括我很欣赏的观点，“我会说'不同'而不是'改善'。” 也有关于JDK 7如何避免 JDK 6中可能发生的潜在内存泄漏的解释。

StackOverflow线程Java 7字符串–子字符串的复杂性解释了更改的动机，并引用了JDK-4513622错误：（str）保留字段的子字符串会阻止对象的GC 。该错误指出：“ [发生OutOfMemory错误，因为如果调用者在对象中存储字段的子字符串，则对象不会被垃圾回收。” 该错误包含演示此错误发生的示例代码。我在这里修改了该代码：

/*** Minimally adapted from Bug JDK-4513622.** {@link http://bugs.java.com/view_bug.do?bug_id=4513622}*/
public class TestGC
{private String largeString = new String(new byte[100000]);private String getString(){return this.largeString.substring(0,2);}public static void main(String[] args){java.util.ArrayList<String> list = new java.util.ArrayList<String>();for (int i = 0; i < 1000000; i++){final TestGC gc = new TestGC();list.add(gc.getString());}}
}

下一个屏幕快照演示了用Java 6（jdk1.6是可执行Java启动程序路径的一部分）和Java 8（主机上的默认版本）执行的最后一个代码段（从Bug JDK-4513622改编而成）。如屏幕快照所示，在Java 6中运行代码时抛出OutOfMemoryError ，而在Java 8中运行时不抛出OutOfMemoryError 。

demoTestGCForJdk4513622

换句话说，当对冗长的Java字符串执行String.substring时，Java 7中的更改修复了潜在的内存泄漏，但以性能影响为代价。这意味着使用String.substring （包括Ant的LineContainsRegExp）来处理很长的行的任何实现都可能需要更改以不同的方式实现，或者在从Java 6迁移到Java 7或更高版本时处理很长的行时应避免使用。

一旦知道了问题（在这种情况下更改String.substring实现），就可以更轻松地在线找到有关正在发生的事情的文档（感谢提供了使这些资源易于查找的注释）。 JDK-4513622的重复错误包含提供额外详细信息的内容。这些错误是JDK-4637640：由于String.substring（）实现而导致的内存泄漏和JDK-6294060：使用substring（）导致了内存泄漏。其他相关的在线资源包括Java 7中对String.substring的更改（其中包括对String.intern（）的引用-有更好的方法）， Java 6与Java 7：当实现很重要时，以及受到高度评价（超过350条注释） Reddit线程TIL Oracle更改了Java 7 Update 6中的内部String表示，从而将子字符串方法的运行时间从常量更改为N。

用Java 1.7.0_06编写的“更改为String内部表示形式”一文很好地回顾了此更改，并总结了原始问题，修复程序以及与该修复程序相关的新问题：