一文梳理Java超大型文件讀取的18種方法和性能
Java 讀取超大文本文件最快速、最可靠的方式是哪幾種?
網(wǎng)上相當多的文檔都存在錯誤,不要輕信。如亂碼問題、半讀問題、資源泄露、性能問題、內(nèi)存溢出問題!
如果面試問到這個問題,也許 10 個人中僅有 1 個人能寫出合格的代碼!雖然Java 程序員不經(jīng)常遇到文件讀寫場景,但這是一個優(yōu)秀程序員的基本功。
首先列出測評結(jié)論,稍后給出詳細介紹和代碼。 建議收藏慢慢看~
性能評測結(jié)果
1 按字節(jié)(字符)讀取
InputStreamReader+ BufferedReader 方式較好,推薦使用。
序號 | 方式 | 耗時 (秒) | 備注 |
---|---|---|---|
1 | Files.readAllBytes (字節(jié)) | 1.2384915 | 一次性加載到內(nèi)存,存在 OOM 風險。且不支持指定字符編碼,存在亂碼問題 |
2 | 推薦 InputStreamReader+ BufferedReader (字符) | 0.987749583 | 性能最好,無 OOM 風險,大小文件均適合。且支持指定字符編碼 |
3 | FileReader + BufferedReader (字符) | 1.058886583 | 性能較好,但不支持指定字符編碼,存在亂碼問題,不推薦使用! |
4 | Scanner | / | 不支持按字符讀取 |
5 | RandomAccessFile (字節(jié)) | 0.374973291 | 僅支持按字節(jié)讀取,不支持字符讀取,因此不推薦讀取文本文件 |
6 | Guava Files | / | 不支持按字符讀取 |
7 | FileChannel + ByteBuffer + CharBuffer (字節(jié),字符) | 0.852993416 | 支持指定字符編碼,性能雖好,但不如 BIO 方式。并且代碼非常復雜,容易出錯,謹慎使用 |
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
序號 | 方式 | 耗時 | 備注 |
---|---|---|---|
1.1 | Files.readAllLines | 3.154415958 | 內(nèi)部按行讀取參考 BufferedReader,然而需要將全部數(shù)據(jù)存放到 List 中,存在 GC 壓力 |
1.2 | 推薦 Files.lines | 2.486005583 | 內(nèi)部通過BufferedReader實現(xiàn)按行讀取,無需全部數(shù)據(jù)到內(nèi)存,每次循環(huán)處理前讀取文件,無GC 壓力。使用方式簡單 |
1.3 | common-io FileUtils.readLines | 3.59483125 | 內(nèi)部實現(xiàn)原理和 Files.readAllLines相同 |
2 | 推薦 InputStreamReader+ BufferedReader | 2.549001042 | 支持指定字符編碼,性能較好,很多工具類均依賴此類實現(xiàn)按行讀取 |
3 | FileReader + BufferedReader | 2.433327333 | 不支持指定字符編碼,存在亂碼問題,不推薦使用 |
4 | Scanner | 15.108729042 | 支持指定字符編碼,性能極差,適合讀取小文件和正則表達式掃描讀取文件 |
5 | RandomAccessFile | 699.56510667 | 不支持指定字符編碼,存在亂碼問題,性能極差。不推薦使用 |
6 | 推薦 Guava Files.readLines | 3.248319917 秒 | 支持指定字符編碼,無需全部讀取后進行業(yè)務處理,性能較好,使用簡單,無需釋放 IO 流 |
7 | FileChannel + ByteBuffer+ CharBuffer | 3.10733875 | 支持指定字符編碼,性能較好,但使用方式復雜。這是因為需要處理半讀問題,自行處理按行讀取問題 |
8 | FileChannel + 直接內(nèi)存 | 7.09936925 | 支持指定字符編碼,性能較差。使用方式復雜。這是因為需要處理半讀問題,自行處理按行讀取問題 |
9 | FileChannel + MappedByteBuffer | 8.264657084 | 支持指定字符編碼,性能較差。使用方式復雜。這是因為需要處理半讀問題,自行處理按行讀取問題 |
接下來,五陽將介紹讀取文件的幾種方式!
0. 前期準備工作
0.1 文件讀取方式
大部分情況下,文件讀取包含以下兩種形式。
- 按行讀取字符文件
- 按字節(jié)讀取文件
0.2 生成大文件
為了測試大文件讀取的性能,需要生成一個大文件!
以下命令在 Mac下測試通過,它可以隨機生成 字符文件,1500000 行,每行 1000 個字符,文件大小約 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 編碼。因為在實際開發(fā)中經(jīng)常遇到文件讀取亂碼問題,如果文件包含中文,若文件讀取代碼塊未正確處理編碼,就會有問題。
因此我在文件中手動補充 稀土掘金 4 個漢字方便排查亂碼 bug,保存文件后,文件字符編碼為 UTF-8。
0.3 JVM 配置
- java 8
- JVM 新生代 4G,堆大小 6G
- 最大堆外內(nèi)存 2g
JVM 啟動參數(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)閉文件的風險,似乎 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,耗時:%s秒", bytes.length, stopWatch.getTotalTimeSeconds()); System.out.println(msg);
輸出 文件字節(jié)長度:1501500012,耗時:1.2384915秒
由于此種方式是一次性將文件讀取到內(nèi)存中,要注意它僅適合讀取小文件,如果目標文件是大文件,可能會出現(xiàn) OOM。
1.2 堆外內(nèi)存
Java 在讀取文件時,會首先將文件內(nèi)存讀取到 堆外內(nèi)存,再從堆外內(nèi)存拷貝到堆內(nèi)存。
為什么呢?
因為JVM 在調(diào)用操作系統(tǒng) API 讀取文件時,需要指定內(nèi)存地址。如果該內(nèi)存地址指向的是Java堆內(nèi)內(nèi)存的話,那么如果操作系統(tǒng)正在訪問這個內(nèi)存地址的時候,Java在這個時候進行了GC操作,而GC操作會涉及到對象移動操作。GC 完成后,將導致傳遞給操作系統(tǒng)的內(nèi)存地址并非 GC后的對象地址,進而導致無法預期的行為! 例如GC時對象從Eden區(qū)移動到 Survivor區(qū),或者被拷貝到老年代。
而 堆外的直接內(nèi)存是 JVM 從操作系統(tǒng) malloc 申請的內(nèi)存,不在堆內(nèi),不會有 GC,不存在被 GC 移動地址的情況!所以堆外內(nèi)存地址傳遞給操作系統(tǒng)是可靠的?。m然多一次的內(nèi)存拷貝,導致性能存在損耗)
因此如果需要將文件讀取到堆內(nèi)存,首先 JVM 會將其讀取到堆外直接內(nèi)存。 如果堆外直接內(nèi)存空間不足,就會出現(xiàn) OOM 異常。
我遇到了如下的異常堆棧問題。起初我在設置 JVM 啟動參數(shù)時,指定了 -XX:MaxDirectMemorySize=1g,也就是將最大堆外內(nèi)存限制為 1G。但由于文件大小達 1.4 G,導致程序出現(xiàn)OOM 異常。后來我將堆外內(nèi)存的上限提高到 2G,問題便得以解決。 然而第一次讀取順利,但是第二次讀取時依然出現(xiàn)了直接內(nèi)存不足的問題。
猜測是因為直接內(nèi)存分配后沒有被及時釋放,導致了內(nèi)存泄露!果不其然,當粗略追蹤了JDK代碼,我發(fā)現(xiàn) jdk 在申請直接內(nèi)存用來讀取文件后,并沒有釋放直接內(nèi)存,而是保存在線程局部變量中用來復用。申請的直接內(nèi)存較小時,問題不明顯。但是一旦當直接內(nèi)存過大時,會出現(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)存時,直接內(nèi)存不足,導致內(nèi)存溢出錯誤。
1.3 Files.readAllLines 一次性按行讀取
內(nèi)部實現(xiàn)時委托了 BufferedReader(第二節(jié)會介紹) 按行讀取,讀取的數(shù)據(jù)按行放在 List 中,因此存在較大的 GC 壓力,對于超大文件,有 OOM 風險。
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,耗時:%s秒", lines.size(), stopWatch.getTotalTimeSeconds()); System.out.println(msg);
輸出 文件行數(shù):1500000,耗時:3.154415958秒
耗時 3.15 秒,比按字節(jié)方式(1.2 秒)讀取慢!
1.4 Files.lines 分行讀取
JDK 自帶的 Files 類不僅提供了將所有數(shù)據(jù)加載到內(nèi)存中的文件讀取方法,還提供了 Files.lines 方法。該方法實現(xiàn)了 Itemator 的迭代接口,使得每次循環(huán)時才逐行讀取文件,不會將所有行全部加載到內(nèi)存中再進行業(yè)務處理。
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è)務邏輯處理 sum.addAndGet(c.length()); lineNum.incrementAndGet(); }); } stopWatch.stop(); String msg = String.format("文件字符數(shù):%s, 文件行數(shù):%s,耗時:%s秒", sum.get(), lineNum.get(), stopWatch.getTotalTimeSeconds()); System.out.println(msg);
輸出:文件字符數(shù):1500000004, 文件行數(shù):1500000,耗時:2.486005583
在 stream.forEach()
方法中統(tǒng)計行數(shù)和字符數(shù)。
以下代碼片段展示了 Files.lines 方法的內(nèi)部實現(xiàn)。Files.lines 返回一個 Stream,該流內(nèi)部封裝了一個迭代器 Iterator。在通過 Stream 進行循環(huán)處理時,每次循環(huán)之前都會按行讀取文件。
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)存中可能會帶來 OOM 風險和 GC 壓力。而使用 Files.lines 方法則無需在讀取過程中將所有數(shù)據(jù)加載到內(nèi)存后再進行業(yè)務處理,因此是一種更為有效的方案。
需要特別注意的是,F(xiàn)iles.lines 返回的 Stream 內(nèi)部包含了 BufferedReader 等 IO 流,這些流在讀取完文件后需要關(guān)閉。此外,F(xiàn)iles.lines 創(chuàng)建的 Stream 也不支持二次讀取。因此,應通過使用 try-with-resources 代碼塊來確保 IO 流在使用完畢后被正確關(guān)閉。
// 自動關(guān)閉 io 流 try (Stream<String> stream = Files.lines(path, StandardCharsets.UTF_8);) { stream.forEach((lineData) -> { //處理業(yè)務邏輯 }); }
1.5 common-io FileUtils 按行讀取
在 common-io 代碼庫中,F(xiàn)ileUtils 提供了按行讀取、一次返回全部行數(shù)據(jù)的能力。其實現(xiàn)原理 1.3節(jié) 中的 Files 類似,因此兩者的性能基本相當??紤]到這一點,建議優(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,耗時:%s秒", lines.size(), stopWatch.getTotalTimeSeconds()); System.out.println(msg);
輸出:文件行數(shù):1500000,耗時: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 + ": 時間:" + stopWatch.getTotalTimeSeconds()); }
輸出 文件字符長度:1501500004: 時間:0.987749583
為什么字符長度是 1501500004? 因為每行 1000 個字符,行末尾包含一個換行符,所以一共 1501500000,我在文件開頭手動添加了 4 個漢字,所以總字符數(shù)在 1501500004。 每個漢字 共 3 個字節(jié),所以文件的總字節(jié)數(shù) 是1501500012。
代碼解讀
- 可以將 FileInputStream、BufferedReader等 需要關(guān)閉的流對象,放在 try () 代碼塊中,JVM會自動調(diào)用 close 方法關(guān)閉流。這樣做代碼更加簡潔和安全。
- BufferedReader 需要聲明緩沖區(qū)大小。 其中 BufferedReader 中緩沖區(qū)大小是指 JVM 調(diào)用操作系統(tǒng)讀取文件時的每批次大小。 而 BufferReader#read 的緩沖區(qū)大小,是指開發(fā)者指定從 BufferedReader 中每次讀取多少數(shù)據(jù)??梢灾付▋烧邽橄嗤?。(建議設置為 1M 即可,不要太大或太?。?/li>
- BufferedReader#read 方法返回了讀取的字符數(shù)量,如到達文件末尾會返回-1。通過 sum+= n 即可獲取讀取的字符數(shù)。會出現(xiàn)讀取的字符數(shù)小于 char 緩沖區(qū)大小的情況,要注意這個問題,避免讀取無效數(shù)據(jù)!
- InputStreamReader 指定了字符集! 讀取字符文件一定要聲明字符文件的編碼,不然遇到中文一定會出現(xiàn)編碼問題。
因為 中文編碼使用 UTF-8 時,是變長的,如稀土掘金一共 12 個字節(jié),每個漢字 3 字節(jié)。如果按照 ASCII 方式讀取,將讀取 12 個字符,就會出現(xiàn)亂碼問題!
后續(xù)的其他文件讀取模版也會出現(xiàn)亂碼問題,屆時我再提醒大家注意!
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 + ": 時間:" + stopWatch.getTotalTimeSeconds()); }
輸出 文件行數(shù):1500000: 時間: 2.549001042
秒 比按字節(jié)方式(0.98 秒)讀取慢!
3. FileReader + BufferedReader
FileReader 的構(gòu)造方法無法指定字符集,其內(nèi)部使用 默認字符集來讀取字符文件! 在 MAC 和 linux 下默認字符集是 UTF-8,但是在 windows 系統(tǒng)中,可能為 GBK!
所以不建議使用 FileReader,兩個原因;1)不支持配置字符集,無法讀取其他字符集文件 2)不同平臺的默認字符集不一樣,代碼不具備移植性。
另外需要強調(diào)一點,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 + ": 時間:" + stopWatch.getTotalTimeSeconds()); }
輸出:文件字符長度:1501500004: 時間: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 + ": 時間:" + stopWatch.getTotalTimeSeconds()); }
輸出 文件行數(shù):1500000: 時間:2.433327333
比按照字符方式(1.05 秒)讀取慢!
4. Scanner
Scanner 僅支持按行讀取文件,可以指定字符集。通過 scanner.nextLine 讀取下一行。然而評測過后發(fā)現(xiàn)此種方式讀取較慢,推薦用來讀取小文件。
為什么 Scanner 按行讀取慢? 因為 Scanner 不僅僅提供按行讀取文件,它具備正則表達式掃描文件的功能,如指定數(shù)字正則表達式,將文件中的所有數(shù)字均提取出來。
Scanner.next( pattern )
, 可根據(jù)正則表達式掃描文件。相比 BufferedReader 等按行讀取,Scanner 的實現(xiàn)邏輯更為復雜,所以性能最差。
因此復雜的文件內(nèi)容掃描推薦使用 Scanner,若僅按行讀取文件,不要使用 Scanner!
根據(jù) nextLine 方法源碼,可以看到內(nèi)部使用了 正則表達式 匹配換行符!
按行讀取文件
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 + ": 時間:" + stopWatch.getTotalTimeSeconds()); }
輸出 文件行數(shù):1500000: 時間:15.108729042
相比其他按行讀取文件方式,Scanner 性能較差!
5. RandomAccessFile
RandomAccessFile父類是 Object ,該類不在 java io復雜的繼承體系下。
支持隨機讀寫文件,支持按行和按字節(jié)方式讀取文件,不支持按照字符方式讀取文件。 這里說明下,按照字節(jié)和字符方式讀取文件的差異!
按照字節(jié)讀取方式最簡單,即讀取文件時,每 8bit即為 1 個字節(jié)!
按照字符方式讀取文件,需要使用方指定 字符編碼集! 否則會出現(xiàn)亂碼問題。 而 RandomAccessFile并未提供 按照字符方式讀取文件的 API!
實際上 RandomAccessFile 提供了 getChar 方式讀取字符,但是默認情況下 getChar 使用 JDK默認的字符編碼: UTF-16,該編碼方式固定 2 個字節(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 + ": 時間:" + stopWatch.getTotalTimeSeconds()); }
輸出 文件字節(jié)數(shù):1501500012: 時間:0.374973291
5.2 按行讀取文件
RandomAccessFile 按行讀取文件性能極差!為了縮短測試時間,我替換了 原 1.4G 的測試文件,改為 140M 的測試文件。
經(jīng)過測試后發(fā)現(xiàn)需要 69.9 秒,如果乘以 10 倍則為 699 秒,遠遠慢于其他按行讀取方式。
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 + ": 時間:" + stopWatch.getTotalTimeSeconds()); }
輸出 文件行數(shù):150000: 時間:69.956510667
為什么性能如此差呢?通過查看源碼可以知道 RandomAccessFile 按行讀取時,是通過調(diào)用 read native 方法,每次讀取 1 個字符,如果該字符為換行符,那么則視為一行數(shù)據(jù)。
當文件數(shù)據(jù)量較大時,每次僅讀取 1 個字符,會導致大量的系統(tǒng)調(diào)用!性能極差!
要實現(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)部自己實現(xiàn)了按行讀取能力。它通過提供回調(diào)接口供使用方獲取每行數(shù)據(jù)。例如如下代碼中的回調(diào)方法實現(xiàn)了業(yè)務邏輯: i++ 計算行數(shù)。
使用此種方式無需關(guān)心關(guān)閉 IO 流,guava 內(nèi)部會處理好,使用起來比較方便,但是不支持按字符讀取
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,耗時:%s秒", lineNums, stopWatch.getTotalTimeSeconds()); System.out.println(msg);
輸出:文件行數(shù):1500000,耗時: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 + ": 時間:" + stopWatch.getTotalTimeSeconds()); }
輸出 文件字符長度:1501560824: 時間:0.893342459
雖然讀取性能很快的,但是輸出結(jié)果的字符長度和預期不一致 為什么呢?
由于文件內(nèi)容編碼方式為 UTF-8即不定長編碼字符集,讀取文件指定的緩沖區(qū)大小無法嚴格保證恰好讀取完整的字符,會存在半讀問題。
String str = new String(byteBuffer.array());
這種轉(zhuǎn)換方式存在亂碼問題!
我重新生成了一個純中文文件,文件內(nèi)容為 4600 個字符,其中換行符 64 個,中文字符4536 個!按照如上錯誤的代碼讀取文件結(jié)果顯示,存在亂碼問題,字符總數(shù)也是錯誤的(輸出4725個,多于正確值4600?。?/p>
因此需要想辦法解決半讀(亂碼)問題
方法 1(不推薦):解析 ByteBuffer 字節(jié)緩沖區(qū),當遇到換行符暫停,進行一次解碼。由于此種方式比較復雜,因此極不推薦,具體方法參考: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 + ": 時間:" + stopWatch.getTotalTimeSeconds()); }
輸出:文件字符長度:4600: 時間:0.00335975
輸出結(jié)果正確!
關(guān)鍵代碼解讀
聲明編碼字符集,創(chuàng)建解碼 Decoder
CharsetDecoder decoder = StandardCharsets.UTF_8.newDecoder();
將字節(jié)數(shù)組 ByteBuffer 解碼存儲到 CharBuffer
CharBuffer charBuffer = CharBuffer.allocate(100);
decoder.decode(byteBuffer, charBuffer, true);
整理剩余未解碼的字節(jié)數(shù)組到緩沖區(qū)頭部。如字節(jié)數(shù)組 1024 長度,當讀取到 1022 時發(fā)現(xiàn)剩余字符無法完全讀取,還剩 2 個字節(jié)未完全讀取,則將 1022 和 1023 兩個字節(jié)數(shù)據(jù)拷貝到 0 和 1,并且設置 position 為 2,那么當下一次 FileChannel.read(byteBuffer)時,新讀取的數(shù)據(jù)則放到緩沖區(qū)數(shù)組 2 的位置。這樣就能避免半讀問題,避免出現(xiàn)亂碼情況!
byteBuffer.compact();
compact 方法的源代碼如下,該方法會將未讀取的字節(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 + ": 時間:" + stopWatch.getTotalTimeSeconds()); }
輸出結(jié)果:文件字符長度:1501500004: 時間:0.852993416
結(jié)果正確,性能也是不錯的
7.4 ByteBuffer.getChar 的亂碼問題
一開始我認為 ByteBuffer的 getChar 方法能按照字符讀取文件,然后經(jīng)過測試后,發(fā)現(xiàn) getChar 會遇到亂碼問題。
getChar 在解碼時,使用了 java char 基礎(chǔ)數(shù)據(jù)類型的編碼集 UTF-16,按固定長度 2 個字節(jié)進行解碼!
無論文件的字符編碼是 UTF-8 還是 ascii ,使用 getChar 均存在亂碼問題!這是因為 UTF-8 是非固定編碼集,ascii 是 1 個字節(jié),而 UTF-16 是兩個字節(jié)!
7.5 按行讀取文件
ByteBuffer 和 CharBuffer 均未提供按行讀取文件的 API,因此需要開發(fā)者自己 實現(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 + ": 時間:" + stopWatch.getTotalTimeSeconds());
輸出 行數(shù):1500000: 時間: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,當存在換行符時,則拼接為一行
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)實現(xiàn)和 堆外實現(xiàn),ByteBuffer.allocate
是在堆內(nèi)申請的緩沖區(qū)。 ByteBuffer.allocateDirect
是在堆外申請緩沖區(qū),讀取文件時無需拷貝到堆內(nèi)存,減少了一次內(nèi)存拷貝操作,性能會更好,然而我的評測結(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 + ": 時間:" + stopWatch.getTotalTimeSeconds()); }
輸出:文件字符長度:1501500004: 時間: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 + ": 時間:" + stopWatch.getTotalTimeSeconds());
輸出: 行數(shù):1500000: 時間:7.09936925
秒
8.3 為什么堆外(直接)內(nèi)存的性能更差呢?
堆外內(nèi)存相較于堆內(nèi)存具有以下幾大優(yōu)勢
- 減少了一次從堆外到堆內(nèi)的拷貝操作。
- 不存在垃圾回收(GC)問題。
似乎堆外內(nèi)存的性能應該強于堆內(nèi)存,然而事與愿違!
在代碼示例中,需要將 ByteBuffer 中的字節(jié)數(shù)組轉(zhuǎn)換為 CharBuffer,因此必須逐個字節(jié)地讀取 ByteBuffer。這正是性能下降的主要原因。
在 HeapByteBuffer 中,get 方法用于獲取指定的字節(jié),通過 array[i] 的數(shù)組下標方式進行訪問,因而性能非常好。
然而,在 DirectByteBuffer 中,讀取指定字節(jié)時無法使用數(shù)組下標直接訪問數(shù)據(jù),而是通過調(diào)用 Unsafe.getByte 方法來實現(xiàn)。由于 Unsafe.getByte 是一個 Java 的本地方法,其性能遠不如直接使用數(shù)組下標訪問來的高效。
public byte get(int i) { return ((unsafe.getByte(ix(checkIndex(i))))); }
9. MappedByteBuffer 讀取文件
和 HeapByteBuffer 不同,MappedByteBuffer 通過操作系統(tǒng)底層 API mmap 將操作系統(tǒng)頁緩存映射到 Java 進程的地址空間。相比堆內(nèi)存緩沖區(qū),MappedByteBuffer 可以減少 2 次內(nèi)存拷貝操作。
從性能的角度來看,將文件映射到內(nèi)存中通常比通過常規(guī)的讀寫方法讀寫幾十千字節(jié)的數(shù)據(jù)更耗費資源。大多數(shù)操作系統(tǒng)都是這樣的。因此,一般只有在處理相對較大的文件時,將文件映射到內(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 + ": 時間:" + stopWatch.getTotalTimeSeconds());
輸出 文件字符長度:1501500004: 時間:4.111039792
關(guān)鍵代碼解讀
當前位置和映射長度
相比 HeapByteBuffer ,MappedByteBuffer處理文件讀取要更復雜!channel.map 方法需要指定文件映射開始點和映射長度,需要有一個指針 position 標識當前讀取的位置,映射長度使用 mappedSize 標識。
映射長度可以是固定長度嗎?不能,map 方法映射的范圍不能超過文件的大小,所以 position + mappedSize 應小于等于文件長度。
bufferSize 是固定長度 100M,remaingSize 是未讀長度,取兩者最小值作為映射長度(避免超過文件大?。?/p>
long mappedSize = Math.min(bufferSize, remainingSize);
channel.map 底層調(diào)用 mmap 將操作系統(tǒng)頁緩存映射到進程地址空間,position 指定當前讀取位置,mappedSize指定映射長度!
MappedByteBuffer buffer = channel.map(FileChannel.MapMode.READ_ONLY, position, mappedSize);
處理亂碼問題
MappedByteBuffer 需要處理半讀問題,否則會出現(xiàn)亂碼問題。HeapByteBuffer 可以使用 compact 方法將未讀取的數(shù)據(jù)拷貝到緩沖區(qū)頭部,從而解決半讀問題。
然而 每次 map 方法新創(chuàng)建一個 MappedByteBuffer,它不可以多次復用,所以對 MappedByteBuffer 調(diào)用 compact 操作無效!
但是通過修改 position指針也能實現(xiàn)類似的效果。思路是若存在未讀取的數(shù)據(jù),則回退 position 指針!如下代碼中 actualSize 是實際讀取的字節(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 + ": 時間:" + stopWatch.getTotalTimeSeconds());
輸出:文件字符長度:1501500004 行數(shù):1500000: 時間:8.264657084
按字符讀取 CharBuffer,當存在換行符時,則拼接為一行
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ù)組下標方式進行訪問,因而性能非常好。
然而,在 MappedByteBuffer 中,讀取指定字節(jié)時無法使用數(shù)組下標直接訪問數(shù)據(jù),而是通過調(diào)用 Unsafe.getByte 方法來實現(xiàn)。由于 Unsafe.getByte 是一個 Java 的本地方法,其性能遠不如直接使用數(shù)組下標訪問來的高效。
public byte get(int i) { return ((unsafe.getByte(ix(checkIndex(i))))); }
10. 性能評測結(jié)果
10.1 按字節(jié)(字符)讀取
推薦 InputStreamReader+ BufferedReader 方式較好
序號 | 方式 | 耗時 (秒) | 備注 |
---|---|---|---|
1 | Files.readAllBytes (字節(jié)) | 1.2384915 | 一次性加載到內(nèi)存,存在 OOM 風險。且不支持指定字符編碼 |
2 | 推薦 InputStreamReader+ BufferedReader (字符) | 0.987749583 | 性能最好,無 OOM 風險,大小文件均適合。且支持指定字符編碼 |
3 | FileReader + BufferedReader (字符) | 1.058886583 | 性能較好,但不支持指定字符編碼,不推薦使用! |
4 | Scanner | / | 不支持按字符讀取 |
5 | RandomAccessFile (字節(jié)) | 0.374973291 | 僅支持按字節(jié)讀取,不支持字符讀取,因此不推薦讀取文本文件 |
6 | Guava Files | / | 不支持按字符讀取 |
7 | FileChannel + ByteBuffer + CharBuffer (字節(jié),字符) | 0.852993416 | 支持指定字符編碼,性能雖好,但不如 BIO 方式。并且代碼非常復雜,容易出錯,謹慎使用 |
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
序號 | 方式 | 耗時 | 備注 |
---|---|---|---|
1.1 | Files.readAllLines | 3.154415958 | 內(nèi)部按行讀取參考 BufferedReader,然而需要將全部數(shù)據(jù)存放到 List 中,存在 GC 壓力 |
1.2 | 推薦 Files.lines | 2.486005583 | 內(nèi)部通過BufferedReader實現(xiàn)按行讀取,無需全部數(shù)據(jù)到內(nèi)存,每次循環(huán)處理前讀取文件,無GC 壓力。使用方式簡單 |
1.3 | common-io FileUtils.readLines | 3.59483125 | 內(nèi)部實現(xiàn)原理和 Files.readAllLines相同 |
2 | 推薦 InputStreamReader+ BufferedReader | 2.549001042 | 支持指定字符編碼,性能較好,很多工具類均依賴此類實現(xiàn)按行讀取 |
3 | FileReader + BufferedReader | 2.433327333 | 不支持指定字符編碼不推薦使用 |
4 | Scanner | 15.108729042 | 支持指定字符編碼,性能極差,適合讀取小文件和正則表達式掃描讀取文件 |
5 | RandomAccessFile | 699.56510667 | 不支持指定字符編碼,性能極差。不推薦使用 |
6 | 推薦 Guava Files.readLines | 3.248319917 秒 | 支持指定字符編碼,無需全部讀取后進行業(yè)務處理,性能較好,使用簡單,無需釋放 IO 流 |
7 | FileChannel + ByteBuffer+ CharBuffer | 3.10733875 | 支持指定字符編碼,性能較好,但使用方式復雜。這是因為需要處理半讀問題,自行處理按行讀取問題 |
8 | FileChannel + 直接內(nèi)存 | 7.09936925 | 支持指定字符編碼,性能較差。使用方式復雜。這是因為需要處理半讀問題,自行處理按行讀取問題 |
9 | FileChannel + MappedByteBuffer | 8.264657084 | 支持指定字符編碼,性能較差。使用方式復雜。這是因為需要處理半讀問題,自行處理按行讀取問題 |
11. 總結(jié)
文件讀取并不簡單,讀取文本文件需要考慮幾個問題
- 按字節(jié)、按字符還是按行讀取
- 根據(jù)文件的字符編碼方式讀取文本文件,否則出現(xiàn)亂碼問題。
- 分行讀取,分行業(yè)務處理。應避免讀取全部內(nèi)容到內(nèi)存后,才進行業(yè)務處理,否則帶來 OOM 風險和 GC 壓力
- 使用Byte 數(shù)組作為緩沖區(qū)讀取文件,轉(zhuǎn)換字符數(shù)組時,應處理半讀問題。否則導致亂碼問題。
- 及時關(guān)閉 IO 流,否則存在資源泄露風險,導致 OOM。
- FileChannel等 nio方式 讀取文件,相比原BIO 方式非但無性能提升,而且代碼實現(xiàn)更加復雜,容易出錯!
以上就是一文梳理Java超大型文件讀取的18種方法和性能的詳細內(nèi)容,更多關(guān)于Java讀取超大型文件的資料請關(guān)注腳本之家其它相關(guān)文章!
相關(guān)文章
java代碼關(guān)閉tomcat程序及出現(xiàn)問題解析
這篇文章主要介紹了java代碼關(guān)閉tomcat程序 及出現(xiàn)問題解析,本文通過實例代碼給大家介紹的非常詳細,需要的朋友可以參考下2019-05-05Mybatis攔截器實現(xiàn)數(shù)據(jù)權(quán)限的示例代碼
在我們?nèi)粘i_發(fā)過程中,通常會涉及到數(shù)據(jù)權(quán)限問題,本文主要介紹了Mybatis攔截器實現(xiàn)數(shù)據(jù)權(quán)限的示例代碼,文中通過示例代碼介紹的非常詳細,具有一定的參考價值,感興趣的小伙伴們可以參考一下2022-03-03LambdaQueryWrapper的實現(xiàn)原理分析和lambda的序列化問題
這篇文章主要介紹了LambdaQueryWrapper的實現(xiàn)原理分析和lambda的序列化問題,具有很好的參考價值,希望對大家有所幫助。如有錯誤或未考慮完全的地方,望不吝賜教。2022-01-01