一文梳理Java超大型文件讀取的18種方法和性能
Java 讀取超大文本文件最快速、最可靠的方式是哪幾種?
網(wǎng)上相當(dāng)多的文檔都存在錯(cuò)誤,不要輕信。如亂碼問題、半讀問題、資源泄露、性能問題、內(nèi)存溢出問題!
如果面試問到這個(gè)問題,也許 10 個(gè)人中僅有 1 個(gè)人能寫出合格的代碼!雖然Java 程序員不經(jīng)常遇到文件讀寫場景,但這是一個(gè)優(yōu)秀程序員的基本功。
首先列出測評(píng)結(jié)論,稍后給出詳細(xì)介紹和代碼。 建議收藏慢慢看~
性能評(píng)測結(jié)果
1 按字節(jié)(字符)讀取
InputStreamReader+ BufferedReader 方式較好,推薦使用。
| 序號(hào) | 方式 | 耗時(shí) (秒) | 備注 |
|---|---|---|---|
| 1 | Files.readAllBytes (字節(jié)) | 1.2384915 | 一次性加載到內(nèi)存,存在 OOM 風(fēng)險(xiǎn)。且不支持指定字符編碼,存在亂碼問題 |
| 2 | 推薦 InputStreamReader+ BufferedReader (字符) | 0.987749583 | 性能最好,無 OOM 風(fēng)險(xiǎn),大小文件均適合。且支持指定字符編碼 |
| 3 | FileReader + BufferedReader (字符) | 1.058886583 | 性能較好,但不支持指定字符編碼,存在亂碼問題,不推薦使用! |
| 4 | Scanner | / | 不支持按字符讀取 |
| 5 | RandomAccessFile (字節(jié)) | 0.374973291 | 僅支持按字節(jié)讀取,不支持字符讀取,因此不推薦讀取文本文件 |
| 6 | Guava Files | / | 不支持按字符讀取 |
| 7 | FileChannel + ByteBuffer + CharBuffer (字節(jié),字符) | 0.852993416 | 支持指定字符編碼,性能雖好,但不如 BIO 方式。并且代碼非常復(fù)雜,容易出錯(cuò),謹(jǐn)慎使用 |
| 8 | FileChannel + 直接內(nèi)存(字節(jié),字符) | 3.082011625 | 支持指定字符編碼,讀取文本文件到堆內(nèi)存的使用場景,不推薦使用直接內(nèi)存,并且性能較差 |
| 9 | FileChannel + MappedByteBuffer | 4.111039792 | 支持指定字符編碼,讀取文本文件到堆內(nèi)存的使用場景,不推薦使用內(nèi)存映射,并且性能較差 |
2 按行讀取
推薦三種方式
- Files.lines
- InputStreamReader+ BufferedReader
- Guava Files.readLines
| 序號(hào) | 方式 | 耗時(shí) | 備注 |
|---|---|---|---|
| 1.1 | Files.readAllLines | 3.154415958 | 內(nèi)部按行讀取參考 BufferedReader,然而需要將全部數(shù)據(jù)存放到 List 中,存在 GC 壓力 |
| 1.2 | 推薦 Files.lines | 2.486005583 | 內(nèi)部通過BufferedReader實(shí)現(xiàn)按行讀取,無需全部數(shù)據(jù)到內(nèi)存,每次循環(huán)處理前讀取文件,無GC 壓力。使用方式簡單 |
| 1.3 | common-io FileUtils.readLines | 3.59483125 | 內(nèi)部實(shí)現(xiàn)原理和 Files.readAllLines相同 |
| 2 | 推薦 InputStreamReader+ BufferedReader | 2.549001042 | 支持指定字符編碼,性能較好,很多工具類均依賴此類實(shí)現(xiàn)按行讀取 |
| 3 | FileReader + BufferedReader | 2.433327333 | 不支持指定字符編碼,存在亂碼問題,不推薦使用 |
| 4 | Scanner | 15.108729042 | 支持指定字符編碼,性能極差,適合讀取小文件和正則表達(dá)式掃描讀取文件 |
| 5 | RandomAccessFile | 699.56510667 | 不支持指定字符編碼,存在亂碼問題,性能極差。不推薦使用 |
| 6 | 推薦 Guava Files.readLines | 3.248319917 秒 | 支持指定字符編碼,無需全部讀取后進(jìn)行業(yè)務(wù)處理,性能較好,使用簡單,無需釋放 IO 流 |
| 7 | FileChannel + ByteBuffer+ CharBuffer | 3.10733875 | 支持指定字符編碼,性能較好,但使用方式復(fù)雜。這是因?yàn)樾枰幚戆胱x問題,自行處理按行讀取問題 |
| 8 | FileChannel + 直接內(nèi)存 | 7.09936925 | 支持指定字符編碼,性能較差。使用方式復(fù)雜。這是因?yàn)樾枰幚戆胱x問題,自行處理按行讀取問題 |
| 9 | FileChannel + MappedByteBuffer | 8.264657084 | 支持指定字符編碼,性能較差。使用方式復(fù)雜。這是因?yàn)樾枰幚戆胱x問題,自行處理按行讀取問題 |
接下來,五陽將介紹讀取文件的幾種方式!
0. 前期準(zhǔn)備工作
0.1 文件讀取方式
大部分情況下,文件讀取包含以下兩種形式。
- 按行讀取字符文件
- 按字節(jié)讀取文件
0.2 生成大文件
為了測試大文件讀取的性能,需要生成一個(gè)大文件!
以下命令在 Mac下測試通過,它可以隨機(jī)生成 字符文件,1500000 行,每行 1000 個(gè)字符,文件大小約 1.4G。
cat /dev/urandom | LC_ALL=C tr -dc 'a-zA-Z0-9' | fold -w 1000 | head -n 1500000 > random.txt
生成文件后,發(fā)現(xiàn)該文件字符集為 us-ascii 編碼。因?yàn)樵趯?shí)際開發(fā)中經(jīng)常遇到文件讀取亂碼問題,如果文件包含中文,若文件讀取代碼塊未正確處理編碼,就會(huì)有問題。
因此我在文件中手動(dòng)補(bǔ)充 稀土掘金 4 個(gè)漢字方便排查亂碼 bug,保存文件后,文件字符編碼為 UTF-8。
0.3 JVM 配置
- java 8
- JVM 新生代 4G,堆大小 6G
- 最大堆外內(nèi)存 2g
JVM 啟動(dòng)參數(shù)如下,其中 -Xloggc 參數(shù)指定將記錄GC 日志文件路徑。
-Xmx6g -Xms6g -XX:SurvivorRatio=8 -Xmn4g -XX:MetaspaceSize=128m -XX:MaxMetaspaceSize=1g -XX:MaxDirectMemorySize=2g -XX:+HeapDumpOnOutOfMemoryError -XX:+PrintGCCause -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps -XX:+PrintTenuringDistribution -XX:+UnlockDiagnosticVMOptions -XX:ParGCCardsPerStrideChunk=32768 -XX:+PrintCommandLineFlags -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:ParallelCMSThreads=6 -XX:+CMSClassUnloadingEnabled -XX:+UseCMSCompactAtFullCollection -XX:+CMSParallelInitialMarkEnabled -XX:+CMSParallelRemarkEnabled -XX:+CMSScavengeBeforeRemark -XX:+PrintHeapAtGC -XX:CMSFullGCsBeforeCompaction=1 -XX:CMSInitiatingOccupancyFraction=70 -XX:+UseCMSInitiatingOccupancyOnly -XX:+PrintReferenceGC -XX:+ParallelRefProcEnabled -XX:ReservedCodeCacheSize=256M -Xloggc:/Users/user/log/gc.log
1. 一次性加載文件
通過 java.nio.file.Files 一次性將文件內(nèi)容讀取到內(nèi)存,使用此種方式適合讀取小文件。Files 提供了兩種方式,字節(jié)方式和按行讀取方式。 由于封裝了文件讀取操作,使用方無需關(guān)閉 Channel、File、InputStream ,不存在遺漏關(guān)閉文件的風(fēng)險(xiǎn),似乎 File 非常簡潔安全,然而并非如此(后面有討論?。?/p>
1.1 按字節(jié)讀取文件
Files.readAllBytes(path) 一次性加載字節(jié)數(shù)組到 JVM 堆內(nèi)存中。
StopWatch stopWatch = new StopWatch();
stopWatch.start();
Path path = Paths.get(FILE_NAME_1400M);
byte[] bytes = Files.readAllBytes(path);
stopWatch.stop();
String msg = String.format("文件字節(jié)長度:%s,耗時(shí):%s秒", bytes.length, stopWatch.getTotalTimeSeconds());
System.out.println(msg);
輸出 文件字節(jié)長度:1501500012,耗時(shí):1.2384915秒
由于此種方式是一次性將文件讀取到內(nèi)存中,要注意它僅適合讀取小文件,如果目標(biāo)文件是大文件,可能會(huì)出現(xiàn) OOM。
1.2 堆外內(nèi)存
Java 在讀取文件時(shí),會(huì)首先將文件內(nèi)存讀取到 堆外內(nèi)存,再從堆外內(nèi)存拷貝到堆內(nèi)存。
為什么呢?
因?yàn)镴VM 在調(diào)用操作系統(tǒng) API 讀取文件時(shí),需要指定內(nèi)存地址。如果該內(nèi)存地址指向的是Java堆內(nèi)內(nèi)存的話,那么如果操作系統(tǒng)正在訪問這個(gè)內(nèi)存地址的時(shí)候,Java在這個(gè)時(shí)候進(jìn)行了GC操作,而GC操作會(huì)涉及到對象移動(dòng)操作。GC 完成后,將導(dǎo)致傳遞給操作系統(tǒng)的內(nèi)存地址并非 GC后的對象地址,進(jìn)而導(dǎo)致無法預(yù)期的行為! 例如GC時(shí)對象從Eden區(qū)移動(dòng)到 Survivor區(qū),或者被拷貝到老年代。
而 堆外的直接內(nèi)存是 JVM 從操作系統(tǒng) malloc 申請的內(nèi)存,不在堆內(nèi),不會(huì)有 GC,不存在被 GC 移動(dòng)地址的情況!所以堆外內(nèi)存地址傳遞給操作系統(tǒng)是可靠的?。m然多一次的內(nèi)存拷貝,導(dǎo)致性能存在損耗)
因此如果需要將文件讀取到堆內(nèi)存,首先 JVM 會(huì)將其讀取到堆外直接內(nèi)存。 如果堆外直接內(nèi)存空間不足,就會(huì)出現(xiàn) OOM 異常。
我遇到了如下的異常堆棧問題。起初我在設(shè)置 JVM 啟動(dòng)參數(shù)時(shí),指定了 -XX:MaxDirectMemorySize=1g,也就是將最大堆外內(nèi)存限制為 1G。但由于文件大小達(dá) 1.4 G,導(dǎo)致程序出現(xiàn)OOM 異常。后來我將堆外內(nèi)存的上限提高到 2G,問題便得以解決。 然而第一次讀取順利,但是第二次讀取時(shí)依然出現(xiàn)了直接內(nèi)存不足的問題。
猜測是因?yàn)橹苯觾?nèi)存分配后沒有被及時(shí)釋放,導(dǎo)致了內(nèi)存泄露!果不其然,當(dāng)粗略追蹤了JDK代碼,我發(fā)現(xiàn) jdk 在申請直接內(nèi)存用來讀取文件后,并沒有釋放直接內(nèi)存,而是保存在線程局部變量中用來復(fù)用。申請的直接內(nèi)存較小時(shí),問題不明顯。但是一旦當(dāng)直接內(nèi)存過大時(shí),會(huì)出現(xiàn)明顯的內(nèi)存泄漏!
java.lang.OutOfMemoryError: Direct buffer memory at java.nio.Bits.reserveMemory(Bits.java:695) at java.nio.DirectByteBuffer.<init>(DirectByteBuffer.java:123) at java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:311) at sun.nio.ch.Util.getTemporaryDirectBuffer(Util.java:241) at sun.nio.ch.IOUtil.read(IOUtil.java:195) at sun.nio.ch.FileChannelImpl.read(FileChannelImpl.java:159) at sun.nio.ch.ChannelInputStream.read(ChannelInputStream.java:65) at sun.nio.ch.ChannelInputStream.read(ChannelInputStream.java:109) at sun.nio.ch.ChannelInputStream.read(ChannelInputStream.java:103) at java.nio.file.Files.read(Files.java:3105) at java.nio.file.Files.readAllBytes(Files.java:3158)
這表明程序在嘗試分配直接內(nèi)存時(shí),直接內(nèi)存不足,導(dǎo)致內(nèi)存溢出錯(cuò)誤。
1.3 Files.readAllLines 一次性按行讀取
內(nèi)部實(shí)現(xiàn)時(shí)委托了 BufferedReader(第二節(jié)會(huì)介紹) 按行讀取,讀取的數(shù)據(jù)按行放在 List 中,因此存在較大的 GC 壓力,對于超大文件,有 OOM 風(fēng)險(xiǎn)。
List<String> lines = Files.readAllLines(path, StandardCharsets.UTF_8);
StopWatch stopWatch = new StopWatch();
stopWatch.start();
Path path = Paths.get(FILE_NAME_1400M);
List<String> lines = Files.readAllLines(path, StandardCharsets.UTF_8);
stopWatch.stop();
String msg = String.format("文件行數(shù):%s,耗時(shí):%s秒", lines.size(), stopWatch.getTotalTimeSeconds());
System.out.println(msg);
輸出 文件行數(shù):1500000,耗時(shí):3.154415958秒 耗時(shí) 3.15 秒,比按字節(jié)方式(1.2 秒)讀取慢!
1.4 Files.lines 分行讀取
JDK 自帶的 Files 類不僅提供了將所有數(shù)據(jù)加載到內(nèi)存中的文件讀取方法,還提供了 Files.lines 方法。該方法實(shí)現(xiàn)了 Itemator 的迭代接口,使得每次循環(huán)時(shí)才逐行讀取文件,不會(huì)將所有行全部加載到內(nèi)存中再進(jìn)行業(yè)務(wù)處理。
StopWatch stopWatch = new StopWatch();
stopWatch.start();
Path path = Paths.get(FILE_NAME_1400M);
AtomicLong lineNum = new AtomicLong(0);
AtomicLong sum = new AtomicLong(0);
try (Stream<String> stream = Files.lines(path, StandardCharsets.UTF_8);) {
stream.forEach((c) -> {
// 業(yè)務(wù)邏輯處理
sum.addAndGet(c.length());
lineNum.incrementAndGet();
});
}
stopWatch.stop();
String msg = String.format("文件字符數(shù):%s, 文件行數(shù):%s,耗時(shí):%s秒", sum.get(), lineNum.get(), stopWatch.getTotalTimeSeconds());
System.out.println(msg);
輸出:文件字符數(shù):1500000004, 文件行數(shù):1500000,耗時(shí):2.486005583
在 stream.forEach() 方法中統(tǒng)計(jì)行數(shù)和字符數(shù)。
以下代碼片段展示了 Files.lines 方法的內(nèi)部實(shí)現(xiàn)。Files.lines 返回一個(gè) Stream,該流內(nèi)部封裝了一個(gè)迭代器 Iterator。在通過 Stream 進(jìn)行循環(huán)處理時(shí),每次循環(huán)之前都會(huì)按行讀取文件。
public Stream<String> lines() {
Iterator<String> iter = new Iterator<String>() {
String nextLine = null;
@Override
public boolean hasNext() {
if (nextLine != null) {
return true;
} else {
try {
nextLine = readLine();
return (nextLine != null);
} catch (IOException e) {
throw new UncheckedIOException(e);
}
}
}
@Override
public String next() {
if (nextLine != null || hasNext()) {
String line = nextLine;
nextLine = null;
return line;
} else {
throw new NoSuchElementException();
}
}
};
return StreamSupport.stream(Spliterators.spliteratorUnknownSize(
iter, Spliterator.ORDERED | Spliterator.NONNULL), false);
}
對于超大文件,直接將所有數(shù)據(jù)讀取到內(nèi)存中可能會(huì)帶來 OOM 風(fēng)險(xiǎn)和 GC 壓力。而使用 Files.lines 方法則無需在讀取過程中將所有數(shù)據(jù)加載到內(nèi)存后再進(jìn)行業(yè)務(wù)處理,因此是一種更為有效的方案。
需要特別注意的是,F(xiàn)iles.lines 返回的 Stream 內(nèi)部包含了 BufferedReader 等 IO 流,這些流在讀取完文件后需要關(guān)閉。此外,F(xiàn)iles.lines 創(chuàng)建的 Stream 也不支持二次讀取。因此,應(yīng)通過使用 try-with-resources 代碼塊來確保 IO 流在使用完畢后被正確關(guān)閉。
// 自動(dòng)關(guān)閉 io 流
try (Stream<String> stream = Files.lines(path, StandardCharsets.UTF_8);) {
stream.forEach((lineData) -> {
//處理業(yè)務(wù)邏輯
});
}
1.5 common-io FileUtils 按行讀取
在 common-io 代碼庫中,F(xiàn)ileUtils 提供了按行讀取、一次返回全部行數(shù)據(jù)的能力。其實(shí)現(xiàn)原理 1.3節(jié) 中的 Files 類似,因此兩者的性能基本相當(dāng)。考慮到這一點(diǎn),建議優(yōu)先使用 JDK 自帶的 Files 類,避免引入額外的外部代碼庫。
StopWatch stopWatch = new StopWatch();
stopWatch.start();
File file = new File(FILE_NAME_1400M);
List<String> lines = org.apache.commons.io.FileUtils.readLines(file, "UTF-8");
stopWatch.stop();
String msg = String.format("文件行數(shù):%s,耗時(shí):%s秒", lines.size(), stopWatch.getTotalTimeSeconds());
System.out.println(msg);
輸出:文件行數(shù):1500000,耗時(shí):3.59483125秒
<dependency>
<groupId>org.apache.commons</groupId>
<artifactId>commons-io</artifactId>
<version>1.3.2</version>
</dependency>
2. InputStreamReader + BufferedReader
BufferedReader 方式提供了 字節(jié)和按行讀取兩種方式。如果是字節(jié)方式,需要使用方指定 char 緩沖區(qū)大小,緩沖區(qū)大小決定了讀取性能。
2.1 按字符方式讀取代碼示例
StopWatch stopWatch = new StopWatch();
stopWatch.start();
File file = new File(FILE_NAME_1400M);
try (FileInputStream fileInputStream = new FileInputStream(file);
InputStreamReader inputStreamReader = new InputStreamReader(fileInputStream, StandardCharsets.UTF_8);
BufferedReader reader = new BufferedReader(inputStreamReader, 1 * 1024 * 1024);) {
char[] chars = new char[1024 * 1024 * 1];
int n = 0;
int sum = 0;
while ((n = reader.read(chars)) > 0) {
sum += n;
}
stopWatch.stop();
System.out.println("文件字符長度:" + sum + ": 時(shí)間:" + stopWatch.getTotalTimeSeconds());
}
輸出 文件字符長度:1501500004: 時(shí)間:0.987749583
為什么字符長度是 1501500004? 因?yàn)槊啃?1000 個(gè)字符,行末尾包含一個(gè)換行符,所以一共 1501500000,我在文件開頭手動(dòng)添加了 4 個(gè)漢字,所以總字符數(shù)在 1501500004。 每個(gè)漢字 共 3 個(gè)字節(jié),所以文件的總字節(jié)數(shù) 是1501500012。
代碼解讀
- 可以將 FileInputStream、BufferedReader等 需要關(guān)閉的流對象,放在 try () 代碼塊中,JVM會(huì)自動(dòng)調(diào)用 close 方法關(guān)閉流。這樣做代碼更加簡潔和安全。
- BufferedReader 需要聲明緩沖區(qū)大小。 其中 BufferedReader 中緩沖區(qū)大小是指 JVM 調(diào)用操作系統(tǒng)讀取文件時(shí)的每批次大小。 而 BufferReader#read 的緩沖區(qū)大小,是指開發(fā)者指定從 BufferedReader 中每次讀取多少數(shù)據(jù)。可以指定兩者為相同值。(建議設(shè)置為 1M 即可,不要太大或太?。?/li>
- BufferedReader#read 方法返回了讀取的字符數(shù)量,如到達(dá)文件末尾會(huì)返回-1。通過 sum+= n 即可獲取讀取的字符數(shù)。會(huì)出現(xiàn)讀取的字符數(shù)小于 char 緩沖區(qū)大小的情況,要注意這個(gè)問題,避免讀取無效數(shù)據(jù)!
- InputStreamReader 指定了字符集! 讀取字符文件一定要聲明字符文件的編碼,不然遇到中文一定會(huì)出現(xiàn)編碼問題。
因?yàn)?中文編碼使用 UTF-8 時(shí),是變長的,如稀土掘金一共 12 個(gè)字節(jié),每個(gè)漢字 3 字節(jié)。如果按照 ASCII 方式讀取,將讀取 12 個(gè)字符,就會(huì)出現(xiàn)亂碼問題!
后續(xù)的其他文件讀取模版也會(huì)出現(xiàn)亂碼問題,屆時(shí)我再提醒大家注意!
2.2 按行讀取文件示例
BufferedReader.readLine() 按行讀取文件
StopWatch stopWatch = new StopWatch();
stopWatch.start();
File file = new File(FILE_NAME_1400M);
try (FileInputStream fileInputStream = new FileInputStream(file); InputStreamReader inputStreamReader = new InputStreamReader(fileInputStream, StandardCharsets.UTF_8); BufferedReader reader = new BufferedReader(inputStreamReader, 1 * 1024 * 1024);) {
int lineNum = 0;
for (; ; ) {
String str = reader.readLine();
if (str == null) {
break;
}
lineNum++;
}
stopWatch.stop();
System.out.println("文件行數(shù):" + lineNum + ": 時(shí)間:" + stopWatch.getTotalTimeSeconds());
}
輸出 文件行數(shù):1500000: 時(shí)間: 2.549001042秒 比按字節(jié)方式(0.98 秒)讀取慢!
3. FileReader + BufferedReader
FileReader 的構(gòu)造方法無法指定字符集,其內(nèi)部使用 默認(rèn)字符集來讀取字符文件! 在 MAC 和 linux 下默認(rèn)字符集是 UTF-8,但是在 windows 系統(tǒng)中,可能為 GBK!
所以不建議使用 FileReader,兩個(gè)原因;1)不支持配置字符集,無法讀取其他字符集文件 2)不同平臺(tái)的默認(rèn)字符集不一樣,代碼不具備移植性。
另外需要強(qiáng)調(diào)一點(diǎn),XXXXReader 類僅用來讀取字符文件,無法讀取字節(jié)文件。
以下是 FileReader 示例代碼
3.1 按字符方式讀取文件
StopWatch stopWatch = new StopWatch();
stopWatch.start();
File file = new File(FILE_NAME_1400M);
try (FileReader reader = new FileReader(file);
BufferedReader bufferedReader = new BufferedReader(reader, 1 * 1024 * 1024);) {
char[] chars = new char[1024 * 1024 * 1];
int n = 0;
int sum = 0;
while ((n = bufferedReader.read(chars)) > 0) {
sum += n;
}
stopWatch.stop();
System.out.println("文件字符長度:" + sum + ": 時(shí)間:" + stopWatch.getTotalTimeSeconds());
}
輸出:文件字符長度:1501500004: 時(shí)間:1.058886583
3.2 按行讀取文件
BufferedReader 按行讀取文件 bufferedReader.readLine
StopWatch stopWatch = new StopWatch();
stopWatch.start();
File file = new File(FILE_NAME_1400M);
try (FileReader reader = new FileReader(file);
BufferedReader bufferedReader = new BufferedReader(reader, 1 * 1024 * 1024);) {
char[] chars = new char[1024 * 1024 * 1];
int lineNum = 0;
for (; ; ) {
String str = bufferedReader.readLine();
if (str == null) {
break;
}
lineNum++;
}
stopWatch.stop();
System.out.println("文件行數(shù):" + lineNum + ": 時(shí)間:" + stopWatch.getTotalTimeSeconds());
}
輸出 文件行數(shù):1500000: 時(shí)間:2.433327333 比按照字符方式(1.05 秒)讀取慢!
4. Scanner
Scanner 僅支持按行讀取文件,可以指定字符集。通過 scanner.nextLine 讀取下一行。然而評(píng)測過后發(fā)現(xiàn)此種方式讀取較慢,推薦用來讀取小文件。
為什么 Scanner 按行讀取慢? 因?yàn)?Scanner 不僅僅提供按行讀取文件,它具備正則表達(dá)式掃描文件的功能,如指定數(shù)字正則表達(dá)式,將文件中的所有數(shù)字均提取出來。
Scanner.next( pattern ), 可根據(jù)正則表達(dá)式掃描文件。相比 BufferedReader 等按行讀取,Scanner 的實(shí)現(xiàn)邏輯更為復(fù)雜,所以性能最差。
因此復(fù)雜的文件內(nèi)容掃描推薦使用 Scanner,若僅按行讀取文件,不要使用 Scanner!

根據(jù) nextLine 方法源碼,可以看到內(nèi)部使用了 正則表達(dá)式 匹配換行符!
按行讀取文件
StopWatch stopWatch = new StopWatch();
stopWatch.start();
File file = new File(FILE_NAME_1400M);
try (FileInputStream fileInputStream = new FileInputStream(file);
Scanner scanner = new Scanner(fileInputStream, StandardCharsets.UTF_8.name());) {
int end = 0;
int lineNum = 0;
do {
String str = scanner.nextLine();
lineNum++;
} while (scanner.hasNextLine());
stopWatch.stop();
System.out.println("文件行數(shù):" + lineNum + ": 時(shí)間:" + stopWatch.getTotalTimeSeconds());
}
輸出 文件行數(shù):1500000: 時(shí)間:15.108729042 相比其他按行讀取文件方式,Scanner 性能較差!
5. RandomAccessFile
RandomAccessFile父類是 Object ,該類不在 java io復(fù)雜的繼承體系下。
支持隨機(jī)讀寫文件,支持按行和按字節(jié)方式讀取文件,不支持按照字符方式讀取文件。 這里說明下,按照字節(jié)和字符方式讀取文件的差異!
按照字節(jié)讀取方式最簡單,即讀取文件時(shí),每 8bit即為 1 個(gè)字節(jié)!
按照字符方式讀取文件,需要使用方指定 字符編碼集! 否則會(huì)出現(xiàn)亂碼問題。 而 RandomAccessFile并未提供 按照字符方式讀取文件的 API!
實(shí)際上 RandomAccessFile 提供了 getChar 方式讀取字符,但是默認(rèn)情況下 getChar 使用 JDK默認(rèn)的字符編碼: UTF-16,該編碼方式固定 2 個(gè)字節(jié)。然而大多數(shù)文件均為 ASCII 或者 UTF-8 編碼,所以不推薦使用 getChar 讀取字符。
迄今為止,RandomAccessFile 是最快的字節(jié)讀取性能,最慢的按行讀取性能!優(yōu)勢和缺陷均十分明顯!
5.1 按字節(jié)方式讀取
randomAccessFile.read(bytes) 支持按字節(jié)讀取文件!性能極好!
為什么? 通過跟蹤源碼發(fā)現(xiàn) RandomAccessFile 最終調(diào)用 native 訪問按字節(jié)讀取文件。
StopWatch stopWatch = new StopWatch();
stopWatch.start();
try (RandomAccessFile randomAccessFile = new RandomAccessFile(FILE_NAME_1400M, "r")) {
byte[] bytes = new byte[1024 * 1024];
int n = 0;
int sum = 0;
while ((n = randomAccessFile.read(bytes)) > 0) {
sum += n;
}
stopWatch.stop();
System.out.println("文件字節(jié)數(shù):" + sum + ": 時(shí)間:" + stopWatch.getTotalTimeSeconds());
}
輸出 文件字節(jié)數(shù):1501500012: 時(shí)間:0.374973291
5.2 按行讀取文件
RandomAccessFile 按行讀取文件性能極差!為了縮短測試時(shí)間,我替換了 原 1.4G 的測試文件,改為 140M 的測試文件。
經(jīng)過測試后發(fā)現(xiàn)需要 69.9 秒,如果乘以 10 倍則為 699 秒,遠(yuǎn)遠(yuǎn)慢于其他按行讀取方式。
StopWatch stopWatch = new StopWatch();
stopWatch.start();
File file = new File(FILE_NAME_140M);
try (RandomAccessFile randomAccessFile = new RandomAccessFile(FILE_NAME_140M, "r")) {
int lineNum = 0;
for (; ; ) {
//end = randomAccessFile.read(bytes);
String str = randomAccessFile.readLine();
if (str == null) {
break;
}
lineNum++;
}
stopWatch.stop();
System.out.println("文件行數(shù):" + lineNum + ": 時(shí)間:" + stopWatch.getTotalTimeSeconds());
}
輸出 文件行數(shù):150000: 時(shí)間:69.956510667
為什么性能如此差呢?通過查看源碼可以知道 RandomAccessFile 按行讀取時(shí),是通過調(diào)用 read native 方法,每次讀取 1 個(gè)字符,如果該字符為換行符,那么則視為一行數(shù)據(jù)。
當(dāng)文件數(shù)據(jù)量較大時(shí),每次僅讀取 1 個(gè)字符,會(huì)導(dǎo)致大量的系統(tǒng)調(diào)用!性能極差!

要實(shí)現(xiàn)更快速的按行讀取數(shù)據(jù)的方法是什么呢?首先,將數(shù)據(jù)讀取到緩沖區(qū)(Java數(shù)組)中,并在循環(huán)中檢查數(shù)組中的元素是否為換行符。通過這種方式,可以避免頻繁的系統(tǒng)調(diào)用和磁盤訪問,從而顯著提升性能。
6. Guava Files.readLines
按行讀取
Guava中提供了 Files 工具類,可以按行讀取文件。相比其他 readLines 方法依賴 BufferedReader,F(xiàn)iles.readLines 內(nèi)部自己實(shí)現(xiàn)了按行讀取能力。它通過提供回調(diào)接口供使用方獲取每行數(shù)據(jù)。例如如下代碼中的回調(diào)方法實(shí)現(xiàn)了業(yè)務(wù)邏輯: i++ 計(jì)算行數(shù)。
使用此種方式無需關(guān)心關(guān)閉 IO 流,guava 內(nèi)部會(huì)處理好,使用起來比較方便,但是不支持按字符讀取
StopWatch stopWatch = new StopWatch();
stopWatch.start();
File file = new File(FILE_NAME_1400M);
int lineNums = com.google.common.io.Files.readLines(file, StandardCharsets.UTF_8,
new LineProcessor<Integer>() {
int i = 0;
@Override
public boolean processLine(String line) throws IOException {
i++;
return true;
}
@Override
public Integer getResult() {
return i;
}
});
stopWatch.stop();
String msg = String.format("文件行數(shù):%s,耗時(shí):%s秒", lineNums, stopWatch.getTotalTimeSeconds());
System.out.println(msg);
輸出:文件行數(shù):1500000,耗時(shí):3.248319917秒
7. FileChannel + ByteBuffer 讀取文件
Java NIO提供了 FileChannel方式讀取文件。讀取方式僅支持按字節(jié)方式讀取,不支持按行讀取或按字符讀取。
如下代碼塊展示了按字節(jié)讀取文件!
7.1 按字節(jié)讀取
StopWatch stopWatch = new StopWatch();
stopWatch.start();
File file = new File(FILE_NAME_1400M);
int capacity = 1 * 1024 * 1024;//1M
ByteBuffer byteBuffer = ByteBuffer.allocate(capacity);
try (FileInputStream fileInputStream = new FileInputStream(file);
FileChannel channel = fileInputStream.getChannel();) {
long sum = 0;
int index = 0;
while (channel.read(byteBuffer) > 0) {
byteBuffer.flip();
String str = new String(byteBuffer.array());
sum += str.length();
byteBuffer.clear();
}
stopWatch.stop();
System.out.println("文件字符長度:" + sum + ": 時(shí)間:" + stopWatch.getTotalTimeSeconds());
}
輸出 文件字符長度:1501560824: 時(shí)間:0.893342459
雖然讀取性能很快的,但是輸出結(jié)果的字符長度和預(yù)期不一致 為什么呢?
由于文件內(nèi)容編碼方式為 UTF-8即不定長編碼字符集,讀取文件指定的緩沖區(qū)大小無法嚴(yán)格保證恰好讀取完整的字符,會(huì)存在半讀問題。
String str = new String(byteBuffer.array()); 這種轉(zhuǎn)換方式存在亂碼問題!
我重新生成了一個(gè)純中文文件,文件內(nèi)容為 4600 個(gè)字符,其中換行符 64 個(gè),中文字符4536 個(gè)!按照如上錯(cuò)誤的代碼讀取文件結(jié)果顯示,存在亂碼問題,字符總數(shù)也是錯(cuò)誤的(輸出4725個(gè),多于正確值4600?。?/p>

因此需要想辦法解決半讀(亂碼)問題
方法 1(不推薦):解析 ByteBuffer 字節(jié)緩沖區(qū),當(dāng)遇到換行符暫停,進(jìn)行一次解碼。由于此種方式比較復(fù)雜,因此極不推薦,具體方法參考:JAVA NIO按行讀寫大文件出現(xiàn)中文亂碼問題的解決
方法 2(推薦):
7.2 compact 解決半讀問題
Java ByteBuffer中提供了 compact 方法用來解決半讀(亂碼)問題。先看代碼示例
StopWatch stopWatch = new StopWatch();
stopWatch.start();
File file = new File(FILE_NAME_ZHONG_WEN);
int capacity = 1 * 1024;
ByteBuffer byteBuffer = ByteBuffer.allocate(capacity);
CharBuffer charBuffer = CharBuffer.allocate(100);
CharsetDecoder decoder = StandardCharsets.UTF_8.newDecoder();
try (FileInputStream fileInputStream = new FileInputStream(file);
FileChannel channel = fileInputStream.getChannel();) {
long sum = 0;
int index = 0;
while (channel.read(byteBuffer) > 0 || byteBuffer.position() != 0) {
byteBuffer.flip();
decoder.decode(byteBuffer, charBuffer, true);
charBuffer.flip();
String content = charBuffer.toString();
sum += content.length();
System.out.print(content);
byteBuffer.compact();
charBuffer.clear();
}
stopWatch.stop();
System.out.println("文件字符長度:" + sum + ": 時(shí)間:" + stopWatch.getTotalTimeSeconds());
}
輸出:文件字符長度:4600: 時(shí)間:0.00335975
輸出結(jié)果正確!
關(guān)鍵代碼解讀
聲明編碼字符集,創(chuàng)建解碼 Decoder
CharsetDecoder decoder = StandardCharsets.UTF_8.newDecoder();
將字節(jié)數(shù)組 ByteBuffer 解碼存儲(chǔ)到 CharBuffer
CharBuffer charBuffer = CharBuffer.allocate(100);
decoder.decode(byteBuffer, charBuffer, true);
整理剩余未解碼的字節(jié)數(shù)組到緩沖區(qū)頭部。如字節(jié)數(shù)組 1024 長度,當(dāng)讀取到 1022 時(shí)發(fā)現(xiàn)剩余字符無法完全讀取,還剩 2 個(gè)字節(jié)未完全讀取,則將 1022 和 1023 兩個(gè)字節(jié)數(shù)據(jù)拷貝到 0 和 1,并且設(shè)置 position 為 2,那么當(dāng)下一次 FileChannel.read(byteBuffer)時(shí),新讀取的數(shù)據(jù)則放到緩沖區(qū)數(shù)組 2 的位置。這樣就能避免半讀問題,避免出現(xiàn)亂碼情況!
byteBuffer.compact();
compact 方法的源代碼如下,該方法會(huì)將未讀取的字節(jié)拷貝到緩沖區(qū)頭部?。˙yteBuffer 的 position 是操作緩沖區(qū)的指針,compact 拷貝范圍為 position 至 limit)

使用正確的按字符讀取方式的代碼如下
7.3 正確的按字符讀取文件
StopWatch stopWatch = new StopWatch();
stopWatch.start();
File file = new File(FILE_NAME_1400M);
int capacity = 1 * 1024 * 1024;//1k
ByteBuffer byteBuffer = ByteBuffer.allocate(capacity);
CharBuffer charBuffer = CharBuffer.allocate(1024 * 1024);
CharsetDecoder decoder = StandardCharsets.UTF_8.newDecoder();
try (FileInputStream fileInputStream = new FileInputStream(file); FileChannel channel = fileInputStream.getChannel();) {
long sum = 0;
int index = 0;
while (channel.read(byteBuffer) > 0 || byteBuffer.position() != 0) {
byteBuffer.flip();
decoder.decode(byteBuffer, charBuffer, true);
charBuffer.flip();
String content = charBuffer.toString();
sum += content.length();
byteBuffer.compact();
charBuffer.clear();
}
stopWatch.stop();
System.out.println("文件字符長度:" + sum + ": 時(shí)間:" + stopWatch.getTotalTimeSeconds());
}
輸出結(jié)果:文件字符長度:1501500004: 時(shí)間:0.852993416
結(jié)果正確,性能也是不錯(cuò)的
7.4 ByteBuffer.getChar 的亂碼問題
一開始我認(rèn)為 ByteBuffer的 getChar 方法能按照字符讀取文件,然后經(jīng)過測試后,發(fā)現(xiàn) getChar 會(huì)遇到亂碼問題。
getChar 在解碼時(shí),使用了 java char 基礎(chǔ)數(shù)據(jù)類型的編碼集 UTF-16,按固定長度 2 個(gè)字節(jié)進(jìn)行解碼!
無論文件的字符編碼是 UTF-8 還是 ascii ,使用 getChar 均存在亂碼問題!這是因?yàn)?UTF-8 是非固定編碼集,ascii 是 1 個(gè)字節(jié),而 UTF-16 是兩個(gè)字節(jié)!
7.5 按行讀取文件
ByteBuffer 和 CharBuffer 均未提供按行讀取文件的 API,因此需要開發(fā)者自己 實(shí)現(xiàn)!
StopWatch stopWatch = new StopWatch();
stopWatch.start();
Path path = Paths.get(FILE_NAME_1400M);
CharsetDecoder decoder = StandardCharsets.UTF_8.newDecoder();
ByteBuffer buffer = ByteBuffer.allocate(1024 * 1024); // 1M 緩沖區(qū)
CharBuffer charBuffer = CharBuffer.allocate(1024 * 1024);
int sum = 0;
int lineNum = 0;
StringBuilder lineBuilder = new StringBuilder();
File file = new File(FILE_NAME_1400M);
long fileSize = file.length();
System.out.println("文件長度:" + fileSize);
try (FileChannel channel = FileChannel.open(path, StandardOpenOption.READ)) {
while (channel.read(buffer) != -1 || buffer.position() > 0) {
buffer.flip();
decoder.decode(buffer, charBuffer, true);
charBuffer.flip();
while (charBuffer.hasRemaining()) {
char c = charBuffer.get();
if (c == '\n') {
// 找到一行,處理它
lineNum++;
sum += lineBuilder.length();
lineBuilder.setLength(0);
} else if (c != '\r') { // 忽略 \r
lineBuilder.append(c);
}
}
buffer.compact();
charBuffer.clear();
}
// 處理最后一行(如果文件不以換行符結(jié)束)
if (lineBuilder.length() > 0) {
lineNum++;
}
} catch (IOException e) {
e.printStackTrace();
}
stopWatch.stop();
System.out.println(" 行數(shù):" + lineNum + ": 時(shí)間:" + stopWatch.getTotalTimeSeconds());
輸出 行數(shù):1500000: 時(shí)間:3.10733875
關(guān)鍵代碼解讀
指定字符解碼器
CharsetDecoder decoder = StandardCharsets.UTF_8.newDecoder();
創(chuàng)建 ByteBuffer 和 CharBuffer
ByteBuffer buffer = ByteBuffer.allocate(1024 * 1024); // 1M 緩沖區(qū) CharBuffer charBuffer = CharBuffer.allocate(1024 * 1024);
打開文件
FileChannel channel = FileChannel.open(path, StandardOpenOption.READ)
按字符讀取 CharBuffer,當(dāng)存在換行符時(shí),則拼接為一行
while (charBuffer.hasRemaining()) {
char c = charBuffer.get();
if (c == '\n') {
// 找到一行,處理它
lineNum++;
sum += lineBuilder.length();
lineBuilder.setLength(0);//lineBuilder 是 StringBuilder
} else if (c != '\r') { // 忽略 \r
lineBuilder.append(c);
}
}
buffer.compact 解決半讀(亂碼)問題 buffer.compact();
處理文件末尾不以換行符結(jié)束的極端 case
if (lineBuilder.length() > 0) {
lineNum++;
}
8. DirectByteBuffer 讀取文件
ByteBuffer 有堆內(nèi)實(shí)現(xiàn)和 堆外實(shí)現(xiàn),ByteBuffer.allocate是在堆內(nèi)申請的緩沖區(qū)。 ByteBuffer.allocateDirect是在堆外申請緩沖區(qū),讀取文件時(shí)無需拷貝到堆內(nèi)存,減少了一次內(nèi)存拷貝操作,性能會(huì)更好,然而我的評(píng)測結(jié)果并非如此
8.1 按字符方式讀取
StopWatch stopWatch = new StopWatch();
stopWatch.start();
File file = new File(FILE_NAME_1400M);
int capacity = 1 * 1024 * 1024;//1M
ByteBuffer byteBuffer = ByteBuffer.allocateDirect(capacity);
CharBuffer charBuffer = CharBuffer.allocate(1024 * 1024);
CharsetDecoder decoder = StandardCharsets.UTF_8.newDecoder();
try (FileInputStream fileInputStream = new FileInputStream(file);
FileChannel channel = fileInputStream.getChannel();) {
long sum = 0;
int index = 0;
while (channel.read(byteBuffer) > 0 || byteBuffer.position() != 0) {
byteBuffer.flip();
decoder.decode(byteBuffer, charBuffer, true);
charBuffer.flip();
String content = charBuffer.toString();
sum += content.length();
byteBuffer.compact();
charBuffer.clear();
}
stopWatch.stop();
System.out.println("文件字符長度:" + sum + ": 時(shí)間:" + stopWatch.getTotalTimeSeconds());
}
輸出:文件字符長度:1501500004: 時(shí)間:3.082011625 秒
相比堆內(nèi) ByteBuffer,直接內(nèi)存方式讀取的性能反而更差!
8.2 按行讀取文件
StopWatch stopWatch = new StopWatch();
stopWatch.start();
Path path = Paths.get(FILE_NAME_1400M);
CharsetDecoder decoder = StandardCharsets.UTF_8.newDecoder();
ByteBuffer buffer = ByteBuffer.allocateDirect(1024 * 1024); // 1M 緩沖區(qū)
CharBuffer charBuffer = CharBuffer.allocate(1024 * 1024);
int sum = 0;
int lineNum = 0;
StringBuilder lineBuilder = new StringBuilder();
File file = new File(FILE_NAME_1400M);
long fileSize = file.length();
System.out.println("文件長度:" + fileSize);
try (FileChannel channel = FileChannel.open(path, StandardOpenOption.READ)) {
while (channel.read(buffer) != -1 || buffer.position() > 0) {
buffer.flip();
decoder.decode(buffer, charBuffer, true);
charBuffer.flip();
while (charBuffer.hasRemaining()) {
char c = charBuffer.get();
if (c == '\n') {
// 找到一行,處理它
lineNum++;
sum += lineBuilder.length();
lineBuilder.setLength(0);
} else if (c != '\r') { // 忽略 \r
lineBuilder.append(c);
}
}
buffer.compact();
charBuffer.clear();
}
// 處理最后一行(如果文件不以換行符結(jié)束)
if (lineBuilder.length() > 0) {
lineNum++;
}
} catch (IOException e) {
e.printStackTrace();
}
stopWatch.stop();
System.out.println(" 行數(shù):" + lineNum + ": 時(shí)間:" + stopWatch.getTotalTimeSeconds());
輸出: 行數(shù):1500000: 時(shí)間:7.09936925秒
8.3 為什么堆外(直接)內(nèi)存的性能更差呢?
堆外內(nèi)存相較于堆內(nèi)存具有以下幾大優(yōu)勢
- 減少了一次從堆外到堆內(nèi)的拷貝操作。
- 不存在垃圾回收(GC)問題。
似乎堆外內(nèi)存的性能應(yīng)該強(qiáng)于堆內(nèi)存,然而事與愿違!
在代碼示例中,需要將 ByteBuffer 中的字節(jié)數(shù)組轉(zhuǎn)換為 CharBuffer,因此必須逐個(gè)字節(jié)地讀取 ByteBuffer。這正是性能下降的主要原因。
在 HeapByteBuffer 中,get 方法用于獲取指定的字節(jié),通過 array[i] 的數(shù)組下標(biāo)方式進(jìn)行訪問,因而性能非常好。
然而,在 DirectByteBuffer 中,讀取指定字節(jié)時(shí)無法使用數(shù)組下標(biāo)直接訪問數(shù)據(jù),而是通過調(diào)用 Unsafe.getByte 方法來實(shí)現(xiàn)。由于 Unsafe.getByte 是一個(gè) Java 的本地方法,其性能遠(yuǎn)不如直接使用數(shù)組下標(biāo)訪問來的高效。
public byte get(int i) {
return ((unsafe.getByte(ix(checkIndex(i)))));
}
9. MappedByteBuffer 讀取文件
和 HeapByteBuffer 不同,MappedByteBuffer 通過操作系統(tǒng)底層 API mmap 將操作系統(tǒng)頁緩存映射到 Java 進(jìn)程的地址空間。相比堆內(nèi)存緩沖區(qū),MappedByteBuffer 可以減少 2 次內(nèi)存拷貝操作。
從性能的角度來看,將文件映射到內(nèi)存中通常比通過常規(guī)的讀寫方法讀寫幾十千字節(jié)的數(shù)據(jù)更耗費(fèi)資源。大多數(shù)操作系統(tǒng)都是這樣的。因此,一般只有在處理相對較大的文件時(shí),將文件映射到內(nèi)存中才是值得的。
9.1 按字符方式讀取文件
StopWatch stopWatch = new StopWatch();
stopWatch.start();
File file = new File(FILE_NAME_1400M);
try (RandomAccessFile randomAccessFile = new RandomAccessFile(file, "r");
FileChannel channel = randomAccessFile.getChannel()) {
long sum = 0;
long fileSize = channel.size();
long position = 0;
long remainingSize = fileSize;
int bufferSize = 100 * 1024 * 1024; // 100M 緩沖區(qū)大小
CharsetDecoder decoder = StandardCharsets.UTF_8.newDecoder();
CharBuffer charBuffer = CharBuffer.allocate(100 * 1024 * 1024);
while (position < fileSize) {
long mappedSize = Math.min(bufferSize, remainingSize);
MappedByteBuffer buffer = channel.map(FileChannel.MapMode.READ_ONLY, position, mappedSize);
decoder.decode(buffer, charBuffer, true);
charBuffer.flip();
String content = charBuffer.toString();
sum += content.length();
charBuffer.clear();
long actualSize = mappedSize + (buffer.position() - buffer.limit());
position = position + actualSize;
remainingSize -= actualSize;
}
stopWatch.stop();
System.out.println("文件字符長度:" + sum + ": 時(shí)間:" + stopWatch.getTotalTimeSeconds());
輸出 文件字符長度:1501500004: 時(shí)間:4.111039792
關(guān)鍵代碼解讀
當(dāng)前位置和映射長度
相比 HeapByteBuffer ,MappedByteBuffer處理文件讀取要更復(fù)雜!channel.map 方法需要指定文件映射開始點(diǎn)和映射長度,需要有一個(gè)指針 position 標(biāo)識(shí)當(dāng)前讀取的位置,映射長度使用 mappedSize 標(biāo)識(shí)。
映射長度可以是固定長度嗎?不能,map 方法映射的范圍不能超過文件的大小,所以 position + mappedSize 應(yīng)小于等于文件長度。
bufferSize 是固定長度 100M,remaingSize 是未讀長度,取兩者最小值作為映射長度(避免超過文件大?。?/p>
long mappedSize = Math.min(bufferSize, remainingSize);
channel.map 底層調(diào)用 mmap 將操作系統(tǒng)頁緩存映射到進(jìn)程地址空間,position 指定當(dāng)前讀取位置,mappedSize指定映射長度!
MappedByteBuffer buffer = channel.map(FileChannel.MapMode.READ_ONLY, position, mappedSize);
處理亂碼問題
MappedByteBuffer 需要處理半讀問題,否則會(huì)出現(xiàn)亂碼問題。HeapByteBuffer 可以使用 compact 方法將未讀取的數(shù)據(jù)拷貝到緩沖區(qū)頭部,從而解決半讀問題。
然而 每次 map 方法新創(chuàng)建一個(gè) MappedByteBuffer,它不可以多次復(fù)用,所以對 MappedByteBuffer 調(diào)用 compact 操作無效!
但是通過修改 position指針也能實(shí)現(xiàn)類似的效果。思路是若存在未讀取的數(shù)據(jù),則回退 position 指針!如下代碼中 actualSize 是實(shí)際讀取的字節(jié)數(shù)。
long actualSize = mappedSize + (buffer.position() - buffer.limit()); position = position + actualSize; remainingSize -= actualSize;
9.2 按行讀取文件
StopWatch stopWatch = new StopWatch();
stopWatch.start();
File file = new File(FILE_NAME_1400M);
CharsetDecoder decoder = StandardCharsets.UTF_8.newDecoder();
try (FileInputStream fileInputStream = new FileInputStream(file); FileChannel channel = fileInputStream.getChannel();) {
long sum = 0;
long fileSize = channel.size();
int lineNum = 0;
long position = 0;
long remainingSize = fileSize;
int bufferSize = 100 * 1024 * 1024; // 100 MB 緩沖區(qū)大小
StringBuilder lineBuilder = new StringBuilder();
CharBuffer charBuffer = CharBuffer.allocate(100 * 1024 * 1024);
while (position < fileSize) {
long mappedSize = Math.min(bufferSize, remainingSize);
MappedByteBuffer buffer = channel.map(FileChannel.MapMode.READ_ONLY, position, mappedSize);
decoder.decode(buffer, charBuffer, true);
charBuffer.flip();
while (charBuffer.hasRemaining()) {
char c = charBuffer.get();
if (c == '\n') {
lineNum++;
sum++;
lineBuilder.setLength(0);
} else if (c != '\r') { // 忽略 \r
lineBuilder.append(c);
sum++;
}
}
long actualSize = mappedSize + (buffer.position() - buffer.limit());
position = position + actualSize;
remainingSize -= actualSize;
charBuffer.clear();
}
// 處理最后一行(如果文件不以換行符結(jié)束)
if (lineBuilder.length() > 0) {
lineNum++;
}
stopWatch.stop();
System.out.println("文件字符長度:" + sum + " 行數(shù):" + lineNum + ": 時(shí)間:" + stopWatch.getTotalTimeSeconds());
輸出:文件字符長度:1501500004 行數(shù):1500000: 時(shí)間:8.264657084
按字符讀取 CharBuffer,當(dāng)存在換行符時(shí),則拼接為一行
while (charBuffer.hasRemaining()) {
char c = charBuffer.get();
if (c == '\n') {
// 找到一行,處理它
lineNum++;
sum += lineBuilder.length();
lineBuilder.setLength(0);//lineBuilder 是 StringBuilder
} else if (c != '\r') { // 忽略 \r
lineBuilder.append(c);
}
}
處理半讀亂碼問題
long actualSize = mappedSize + (buffer.position() - buffer.limit()); position = position + actualSize; remainingSize -= actualSize;
9.3 為什么 MappedByteBuffer 的讀取性能差
相比堆內(nèi)存讀取方式,MappedByteBuffer 的讀取性能較差,原因和堆外直接內(nèi)存方式相同。
在 HeapByteBuffer 中,get 方法用于獲取指定的字節(jié),通過 array[i] 的數(shù)組下標(biāo)方式進(jìn)行訪問,因而性能非常好。
然而,在 MappedByteBuffer 中,讀取指定字節(jié)時(shí)無法使用數(shù)組下標(biāo)直接訪問數(shù)據(jù),而是通過調(diào)用 Unsafe.getByte 方法來實(shí)現(xiàn)。由于 Unsafe.getByte 是一個(gè) Java 的本地方法,其性能遠(yuǎn)不如直接使用數(shù)組下標(biāo)訪問來的高效。
public byte get(int i) {
return ((unsafe.getByte(ix(checkIndex(i)))));
}
10. 性能評(píng)測結(jié)果
10.1 按字節(jié)(字符)讀取
推薦 InputStreamReader+ BufferedReader 方式較好
| 序號(hào) | 方式 | 耗時(shí) (秒) | 備注 |
|---|---|---|---|
| 1 | Files.readAllBytes (字節(jié)) | 1.2384915 | 一次性加載到內(nèi)存,存在 OOM 風(fēng)險(xiǎn)。且不支持指定字符編碼 |
| 2 | 推薦 InputStreamReader+ BufferedReader (字符) | 0.987749583 | 性能最好,無 OOM 風(fēng)險(xiǎn),大小文件均適合。且支持指定字符編碼 |
| 3 | FileReader + BufferedReader (字符) | 1.058886583 | 性能較好,但不支持指定字符編碼,不推薦使用! |
| 4 | Scanner | / | 不支持按字符讀取 |
| 5 | RandomAccessFile (字節(jié)) | 0.374973291 | 僅支持按字節(jié)讀取,不支持字符讀取,因此不推薦讀取文本文件 |
| 6 | Guava Files | / | 不支持按字符讀取 |
| 7 | FileChannel + ByteBuffer + CharBuffer (字節(jié),字符) | 0.852993416 | 支持指定字符編碼,性能雖好,但不如 BIO 方式。并且代碼非常復(fù)雜,容易出錯(cuò),謹(jǐn)慎使用 |
| 8 | FileChannel + 直接內(nèi)存(字節(jié),字符) | 3.082011625 | 支持指定字符編碼,讀取文本文件到堆內(nèi)存的使用場景,不推薦使用直接內(nèi)存,并且性能較差 |
| 9 | FileChannel + MappedByteBuffer | 4.111039792 | 支持指定字符編碼,讀取文本文件到堆內(nèi)存的使用場景,不推薦使用內(nèi)存映射,并且性能較差 |
10.2 按行讀取
推薦三種方式
- Files.lines
- InputStreamReader+ BufferedReader
- Guava Files.readLines
| 序號(hào) | 方式 | 耗時(shí) | 備注 |
|---|---|---|---|
| 1.1 | Files.readAllLines | 3.154415958 | 內(nèi)部按行讀取參考 BufferedReader,然而需要將全部數(shù)據(jù)存放到 List 中,存在 GC 壓力 |
| 1.2 | 推薦 Files.lines | 2.486005583 | 內(nèi)部通過BufferedReader實(shí)現(xiàn)按行讀取,無需全部數(shù)據(jù)到內(nèi)存,每次循環(huán)處理前讀取文件,無GC 壓力。使用方式簡單 |
| 1.3 | common-io FileUtils.readLines | 3.59483125 | 內(nèi)部實(shí)現(xiàn)原理和 Files.readAllLines相同 |
| 2 | 推薦 InputStreamReader+ BufferedReader | 2.549001042 | 支持指定字符編碼,性能較好,很多工具類均依賴此類實(shí)現(xiàn)按行讀取 |
| 3 | FileReader + BufferedReader | 2.433327333 | 不支持指定字符編碼不推薦使用 |
| 4 | Scanner | 15.108729042 | 支持指定字符編碼,性能極差,適合讀取小文件和正則表達(dá)式掃描讀取文件 |
| 5 | RandomAccessFile | 699.56510667 | 不支持指定字符編碼,性能極差。不推薦使用 |
| 6 | 推薦 Guava Files.readLines | 3.248319917 秒 | 支持指定字符編碼,無需全部讀取后進(jìn)行業(yè)務(wù)處理,性能較好,使用簡單,無需釋放 IO 流 |
| 7 | FileChannel + ByteBuffer+ CharBuffer | 3.10733875 | 支持指定字符編碼,性能較好,但使用方式復(fù)雜。這是因?yàn)樾枰幚戆胱x問題,自行處理按行讀取問題 |
| 8 | FileChannel + 直接內(nèi)存 | 7.09936925 | 支持指定字符編碼,性能較差。使用方式復(fù)雜。這是因?yàn)樾枰幚戆胱x問題,自行處理按行讀取問題 |
| 9 | FileChannel + MappedByteBuffer | 8.264657084 | 支持指定字符編碼,性能較差。使用方式復(fù)雜。這是因?yàn)樾枰幚戆胱x問題,自行處理按行讀取問題 |
11. 總結(jié)
文件讀取并不簡單,讀取文本文件需要考慮幾個(gè)問題
- 按字節(jié)、按字符還是按行讀取
- 根據(jù)文件的字符編碼方式讀取文本文件,否則出現(xiàn)亂碼問題。
- 分行讀取,分行業(yè)務(wù)處理。應(yīng)避免讀取全部內(nèi)容到內(nèi)存后,才進(jìn)行業(yè)務(wù)處理,否則帶來 OOM 風(fēng)險(xiǎn)和 GC 壓力
- 使用Byte 數(shù)組作為緩沖區(qū)讀取文件,轉(zhuǎn)換字符數(shù)組時(shí),應(yīng)處理半讀問題。否則導(dǎo)致亂碼問題。
- 及時(shí)關(guān)閉 IO 流,否則存在資源泄露風(fēng)險(xiǎn),導(dǎo)致 OOM。
- FileChannel等 nio方式 讀取文件,相比原BIO 方式非但無性能提升,而且代碼實(shí)現(xiàn)更加復(fù)雜,容易出錯(cuò)!
以上就是一文梳理Java超大型文件讀取的18種方法和性能的詳細(xì)內(nèi)容,更多關(guān)于Java讀取超大型文件的資料請關(guān)注腳本之家其它相關(guān)文章!
相關(guān)文章
java代碼關(guān)閉tomcat程序及出現(xiàn)問題解析
這篇文章主要介紹了java代碼關(guān)閉tomcat程序 及出現(xiàn)問題解析,本文通過實(shí)例代碼給大家介紹的非常詳細(xì),需要的朋友可以參考下2019-05-05
Mybatis攔截器實(shí)現(xiàn)數(shù)據(jù)權(quán)限的示例代碼
在我們?nèi)粘i_發(fā)過程中,通常會(huì)涉及到數(shù)據(jù)權(quán)限問題,本文主要介紹了Mybatis攔截器實(shí)現(xiàn)數(shù)據(jù)權(quán)限的示例代碼,文中通過示例代碼介紹的非常詳細(xì),具有一定的參考價(jià)值,感興趣的小伙伴們可以參考一下2022-03-03
JavaWeb登錄界面登錄失敗在同一頁面進(jìn)行提示的解決
這篇文章主要介紹了JavaWeb登錄界面登錄失敗在同一頁面進(jìn)行提示的解決,具有很好的參考價(jià)值,希望對大家有所幫助。如有錯(cuò)誤或未考慮完全的地方,望不吝賜教2022-11-11
LambdaQueryWrapper的實(shí)現(xiàn)原理分析和lambda的序列化問題
這篇文章主要介紹了LambdaQueryWrapper的實(shí)現(xiàn)原理分析和lambda的序列化問題,具有很好的參考價(jià)值,希望對大家有所幫助。如有錯(cuò)誤或未考慮完全的地方,望不吝賜教。2022-01-01

