欧美bbbwbbbw肥妇,免费乱码人妻系列日韩,一级黄片

一文梳理Java超大型文件讀取的18種方法和性能

 更新時間:2025年02月18日 08:59:42   作者:五陽  
這篇文章主要為大家詳細介紹了Java中超大型文件讀取的18種方法和性能對比,文中的示例代碼簡潔易懂,感興趣的小伙伴可以跟隨小編一起學習一下

Java 讀取超大文本文件最快速、最可靠的方式是哪幾種?

網(wǎng)上相當多的文檔都存在錯誤,不要輕信。如亂碼問題、半讀問題、資源泄露、性能問題、內(nèi)存溢出問題!

如果面試問到這個問題,也許 10 個人中僅有 1 個人能寫出合格的代碼!雖然Java 程序員不經(jīng)常遇到文件讀寫場景,但這是一個優(yōu)秀程序員的基本功。

首先列出測評結(jié)論,稍后給出詳細介紹和代碼。 建議收藏慢慢看~

性能評測結(jié)果

1 按字節(jié)(字符)讀取

InputStreamReader+ BufferedReader 方式較好,推薦使用。

序號方式耗時 (秒)備注
1Files.readAllBytes (字節(jié))1.2384915一次性加載到內(nèi)存,存在 OOM 風險。且不支持指定字符編碼,存在亂碼問題
2推薦 InputStreamReader+ BufferedReader (字符)0.987749583性能最好,無 OOM 風險,大小文件均適合。且支持指定字符編碼
3FileReader + BufferedReader (字符)1.058886583性能較好,但不支持指定字符編碼,存在亂碼問題,不推薦使用!
4Scanner/不支持按字符讀取
5RandomAccessFile (字節(jié))0.374973291僅支持按字節(jié)讀取,不支持字符讀取,因此不推薦讀取文本文件
6Guava Files/不支持按字符讀取
7FileChannel + ByteBuffer + CharBuffer (字節(jié),字符)0.852993416支持指定字符編碼,性能雖好,但不如 BIO 方式。并且代碼非常復雜,容易出錯,謹慎使用
8FileChannel + 直接內(nèi)存(字節(jié),字符)3.082011625支持指定字符編碼,讀取文本文件到堆內(nèi)存的使用場景,不推薦使用直接內(nèi)存,并且性能較差
9FileChannel + MappedByteBuffer4.111039792支持指定字符編碼,讀取文本文件到堆內(nèi)存的使用場景,不推薦使用內(nèi)存映射,并且性能較差

2 按行讀取

推薦三種方式

  • Files.lines
  • InputStreamReader+ BufferedReader
  • Guava Files.readLines
序號方式耗時備注
1.1Files.readAllLines3.154415958內(nèi)部按行讀取參考 BufferedReader,然而需要將全部數(shù)據(jù)存放到 List 中,存在 GC 壓力
1.2推薦 Files.lines2.486005583內(nèi)部通過BufferedReader實現(xiàn)按行讀取,無需全部數(shù)據(jù)到內(nèi)存,每次循環(huán)處理前讀取文件,無GC 壓力。使用方式簡單
1.3common-io FileUtils.readLines3.59483125內(nèi)部實現(xiàn)原理和 Files.readAllLines相同
2推薦 InputStreamReader+ BufferedReader2.549001042支持指定字符編碼,性能較好,很多工具類均依賴此類實現(xiàn)按行讀取
3FileReader + BufferedReader2.433327333不支持指定字符編碼,存在亂碼問題,不推薦使用
4Scanner15.108729042支持指定字符編碼,性能極差,適合讀取小文件和正則表達式掃描讀取文件
5RandomAccessFile699.56510667不支持指定字符編碼,存在亂碼問題,性能極差。不推薦使用
6推薦 Guava Files.readLines3.248319917 秒支持指定字符編碼,無需全部讀取后進行業(yè)務處理,性能較好,使用簡單,無需釋放 IO 流
7FileChannel + ByteBuffer+ CharBuffer3.10733875支持指定字符編碼,性能較好,但使用方式復雜。這是因為需要處理半讀問題,自行處理按行讀取問題
8FileChannel + 直接內(nèi)存7.09936925支持指定字符編碼,性能較差。使用方式復雜。這是因為需要處理半讀問題,自行處理按行讀取問題
9FileChannel + MappedByteBuffer8.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 方式較好

序號方式耗時 (秒)備注
1Files.readAllBytes (字節(jié))1.2384915一次性加載到內(nèi)存,存在 OOM 風險。且不支持指定字符編碼
2推薦 InputStreamReader+ BufferedReader (字符)0.987749583性能最好,無 OOM 風險,大小文件均適合。且支持指定字符編碼
3FileReader + BufferedReader (字符)1.058886583性能較好,但不支持指定字符編碼,不推薦使用!
4Scanner/不支持按字符讀取
5RandomAccessFile (字節(jié))0.374973291僅支持按字節(jié)讀取,不支持字符讀取,因此不推薦讀取文本文件
6Guava Files/不支持按字符讀取
7FileChannel + ByteBuffer + CharBuffer (字節(jié),字符)0.852993416支持指定字符編碼,性能雖好,但不如 BIO 方式。并且代碼非常復雜,容易出錯,謹慎使用
8FileChannel + 直接內(nèi)存(字節(jié),字符)3.082011625支持指定字符編碼,讀取文本文件到堆內(nèi)存的使用場景,不推薦使用直接內(nèi)存,并且性能較差
9FileChannel + MappedByteBuffer4.111039792支持指定字符編碼,讀取文本文件到堆內(nèi)存的使用場景,不推薦使用內(nèi)存映射,并且性能較差

10.2 按行讀取

推薦三種方式

  • Files.lines
  • InputStreamReader+ BufferedReader
  • Guava Files.readLines
序號方式耗時備注
1.1Files.readAllLines3.154415958內(nèi)部按行讀取參考 BufferedReader,然而需要將全部數(shù)據(jù)存放到 List 中,存在 GC 壓力
1.2推薦 Files.lines2.486005583內(nèi)部通過BufferedReader實現(xiàn)按行讀取,無需全部數(shù)據(jù)到內(nèi)存,每次循環(huán)處理前讀取文件,無GC 壓力。使用方式簡單
1.3common-io FileUtils.readLines3.59483125內(nèi)部實現(xiàn)原理和 Files.readAllLines相同
2推薦 InputStreamReader+ BufferedReader2.549001042支持指定字符編碼,性能較好,很多工具類均依賴此類實現(xiàn)按行讀取
3FileReader + BufferedReader2.433327333不支持指定字符編碼不推薦使用
4Scanner15.108729042支持指定字符編碼,性能極差,適合讀取小文件和正則表達式掃描讀取文件
5RandomAccessFile699.56510667不支持指定字符編碼,性能極差。不推薦使用
6推薦 Guava Files.readLines3.248319917 秒支持指定字符編碼,無需全部讀取后進行業(yè)務處理,性能較好,使用簡單,無需釋放 IO 流
7FileChannel + ByteBuffer+ CharBuffer3.10733875支持指定字符編碼,性能較好,但使用方式復雜。這是因為需要處理半讀問題,自行處理按行讀取問題
8FileChannel + 直接內(nèi)存7.09936925支持指定字符編碼,性能較差。使用方式復雜。這是因為需要處理半讀問題,自行處理按行讀取問題
9FileChannel + MappedByteBuffer8.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并發(fā)編程中的ReentrantLock詳解

    Java并發(fā)編程中的ReentrantLock詳解

    這篇文章主要介紹了Java并發(fā)編程中的ReentrantLock詳解,從Java 5 開始,引入了一個高級的處理并發(fā)的java.util.concurrent包,它提供了大量更高級的并發(fā)功能,能大大簡化多線程程序的編寫,需要的朋友可以參考下
    2023-11-11
  • Java 和 Scala 如何調(diào)用變參

    Java 和 Scala 如何調(diào)用變參

    這篇文章主要介紹了Java 和 Scala 如何調(diào)用變參,幫助大家更好的理解和學習Java與Scala,感興趣的朋友可以了解下
    2020-09-09
  • struts2通過action返回json對象

    struts2通過action返回json對象

    struts2通過action返回json對象其實很簡單的,首先我們需要引入jar包,然后在寫一個簡單的action就好了,接下來通過本文給大家介紹struts2通過action返回json對象的方法,感興趣的朋友一起看看吧
    2016-09-09
  • java jdk動態(tài)代理詳解

    java jdk動態(tài)代理詳解

    動態(tài)代理類的Class實例是怎么生成的呢,是通過ProxyGenerator類來生成動態(tài)代理類的class字節(jié)流,把它載入方法區(qū)
    2013-09-09
  • java代碼關(guān)閉tomcat程序及出現(xiàn)問題解析

    java代碼關(guān)閉tomcat程序及出現(xiàn)問題解析

    這篇文章主要介紹了java代碼關(guān)閉tomcat程序 及出現(xiàn)問題解析,本文通過實例代碼給大家介紹的非常詳細,需要的朋友可以參考下
    2019-05-05
  • Mybatis攔截器實現(xiàn)數(shù)據(jù)權(quán)限的示例代碼

    Mybatis攔截器實現(xiàn)數(shù)據(jù)權(quán)限的示例代碼

    在我們?nèi)粘i_發(fā)過程中,通常會涉及到數(shù)據(jù)權(quán)限問題,本文主要介紹了Mybatis攔截器實現(xiàn)數(shù)據(jù)權(quán)限的示例代碼,文中通過示例代碼介紹的非常詳細,具有一定的參考價值,感興趣的小伙伴們可以參考一下
    2022-03-03
  • 深入理解Java垃圾回收機制以及內(nèi)存泄漏

    深入理解Java垃圾回收機制以及內(nèi)存泄漏

    下面小編就為大家?guī)硪黄钊肜斫釰ava垃圾回收機制以及內(nèi)存泄漏。小編覺得挺不錯的,現(xiàn)在就分享給大家,也給的大家做個參考。一起跟隨小編過來看看吧
    2016-05-05
  • 使用@RequestParam 綁定List參數(shù)

    使用@RequestParam 綁定List參數(shù)

    這篇文章主要介紹了使用@RequestParam 綁定List參數(shù)的操作,具有很好的參考價值,希望對大家有所幫助。如有錯誤或未考慮完全的地方,望不吝賜教
    2021-08-08
  • JavaWeb登錄界面登錄失敗在同一頁面進行提示的解決

    JavaWeb登錄界面登錄失敗在同一頁面進行提示的解決

    這篇文章主要介紹了JavaWeb登錄界面登錄失敗在同一頁面進行提示的解決,具有很好的參考價值,希望對大家有所幫助。如有錯誤或未考慮完全的地方,望不吝賜教
    2022-11-11
  • LambdaQueryWrapper的實現(xiàn)原理分析和lambda的序列化問題

    LambdaQueryWrapper的實現(xiàn)原理分析和lambda的序列化問題

    這篇文章主要介紹了LambdaQueryWrapper的實現(xiàn)原理分析和lambda的序列化問題,具有很好的參考價值,希望對大家有所幫助。如有錯誤或未考慮完全的地方,望不吝賜教。
    2022-01-01

最新評論