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

更新時間：2025年02月18日 08:59:42 作者：五陽

這篇文章主要為大家詳細(xì)介紹了Java中超大型文件讀取的18種方法和性能對比,文中的示例代碼簡潔易懂,感興趣的小伙伴可以跟隨小編一起學(xué)習(xí)一下

性能評測結(jié)果

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

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

序號	方式	耗時 (秒)	備注
1	Files.readAllBytes （字節(jié)）	1.2384915	一次性加載到內(nèi)存，存在 OOM 風(fēng)險。且不支持指定字符編碼，存在亂碼問題
2	推薦 InputStreamReader+ BufferedReader (字符)	0.987749583	性能最好，無 OOM 風(fēng)險，大小文件均適合。且支持指定字符編碼
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ù)雜，容易出錯，謹(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

序號	方式	耗時	備注
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	支持指定字符編碼，性能極差，適合讀取小文件和正則表達(dá)式掃描讀取文件
5	RandomAccessFile	699.56510667	不支持指定字符編碼，存在亂碼問題，性能極差。不推薦使用
6	推薦 Guava Files.readLines	3.248319917 秒	支持指定字符編碼，無需全部讀取后進(jìn)行業(yè)務(wù)處理，性能較好，使用簡單，無需釋放 IO 流
7	FileChannel + ByteBuffer+ CharBuffer	3.10733875	支持指定字符編碼，性能較好，但使用方式復(fù)雜。這是因為需要處理半讀問題，自行處理按行讀取問題
8	FileChannel + 直接內(nèi)存	7.09936925	支持指定字符編碼，性能較差。使用方式復(fù)雜。這是因為需要處理半讀問題，自行處理按行讀取問題
9	FileChannel + MappedByteBuffer	8.264657084	支持指定字符編碼，性能較差。使用方式復(fù)雜。這是因為需要處理半讀問題，自行處理按行讀取問題

接下來，五陽將介紹讀取文件的幾種方式！

0. 前期準(zhǔn)備工作

0.1 文件讀取方式

大部分情況下，文件讀取包含以下兩種形式。

按行讀取字符文件
按字節(jié)讀取文件

0.2 生成大文件

為了測試大文件讀取的性能，需要生成一個大文件！

以下命令在 Mac下測試通過，它可以隨機(jī)生成字符文件，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)閉文件的風(fēng)險，似乎 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)存中，要注意它僅適合讀取小文件，如果目標(biāo)文件是大文件，可能會出現(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在這個時候進(jìn)行了GC操作，而GC操作會涉及到對象移動操作。GC 完成后，將導(dǎo)致傳遞給操作系統(tǒng)的內(nèi)存地址并非 GC后的對象地址，進(jìn)而導(dǎo)致無法預(yù)期的行為! 例如GC時對象從Eden區(qū)移動到 Survivor區(qū)，或者被拷貝到老年代。

而堆外的直接內(nèi)存是 JVM 從操作系統(tǒng) malloc 申請的內(nèi)存，不在堆內(nèi)，不會有 GC，不存在被 GC 移動地址的情況！所以堆外內(nèi)存地址傳遞給操作系統(tǒng)是可靠的?。m然多一次的內(nèi)存拷貝，導(dǎo)致性能存在損耗）

因此如果需要將文件讀取到堆內(nèi)存，首先 JVM 會將其讀取到堆外直接內(nèi)存。如果堆外直接內(nèi)存空間不足，就會出現(xiàn) OOM 異常。

我遇到了如下的異常堆棧問題。起初我在設(shè)置 JVM 啟動參數(shù)時，指定了 -XX:MaxDirectMemorySize=1g，也就是將最大堆外內(nèi)存限制為 1G。但由于文件大小達(dá) 1.4 G，導(dǎo)致程序出現(xiàn)OOM 異常。后來我將堆外內(nèi)存的上限提高到 2G，問題便得以解決。然而第一次讀取順利，但是第二次讀取時依然出現(xiàn)了直接內(nèi)存不足的問題。

猜測是因為直接內(nèi)存分配后沒有被及時釋放，導(dǎo)致了內(nèi)存泄露！果不其然，當(dāng)粗略追蹤了JDK代碼，我發(fā)現(xiàn) jdk 在申請直接內(nèi)存用來讀取文件后，并沒有釋放直接內(nèi)存，而是保存在線程局部變量中用來復(fù)用。申請的直接內(nèi)存較小時，問題不明顯。但是一旦當(dāng)直接內(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)存不足，導(dǎo)致內(nèi)存溢出錯誤。

1.3 Files.readAllLines 一次性按行讀取

內(nèi)部實現(xiàn)時委托了 BufferedReader（第二節(jié)會介紹）按行讀取，讀取的數(shù)據(jù)按行放在 List 中，因此存在較大的 GC 壓力，對于超大文件，有 OOM 風(fēng)險。

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)存中再進(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，耗時:%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 進(jìn)行循環(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 風(fēng)險和 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)閉。

// 自動關(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ù)的能力。其實現(xiàn)原理 1.3節(jié) 中的 Files 類似，因此兩者的性能基本相當(dāng)?？紤]到這一點，建議優(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ù)?？梢灾付▋烧邽橄嗤?。（建議設(shè)置為 1M 即可，不要太大或太?。?/li>
BufferedReader#read 方法返回了讀取的字符數(shù)量，如到達(dá)文件末尾會返回-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)部使用默認(rèn)字符集來讀取字符文件！在 MAC 和 linux 下默認(rèn)字符集是 UTF-8，但是在 windows 系統(tǒng)中，可能為 GBK！

所以不建議使用 FileReader，兩個原因；1）不支持配置字符集，無法讀取其他字符集文件 2）不同平臺的默認(rèn)字符集不一樣，代碼不具備移植性。

另外需要強調(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 不僅僅提供按行讀取文件，它具備正則表達(dá)式掃描文件的功能，如指定數(shù)字正則表達(dá)式，將文件中的所有數(shù)字均提取出來。

Scanner.next( pattern )，可根據(jù)正則表達(dá)式掃描文件。相比 BufferedReader 等按行讀取，Scanner 的實現(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 + ": 時間:" + stopWatch.getTotalTimeSeconds());
}

輸出 文件行數(shù):1500000: 時間:15.108729042 相比其他按行讀取文件方式，Scanner 性能較差！

5. RandomAccessFile

RandomAccessFile父類是 Object ，該類不在 java io復(fù)雜的繼承體系下。

支持隨機(jī)讀寫文件，支持按行和按字節(jié)方式讀取文件，不支持按照字符方式讀取文件。這里說明下，按照字節(jié)和字符方式讀取文件的差異！

按照字節(jié)讀取方式最簡單，即讀取文件時，每 8bit即為 1 個字節(jié)！

按照字符方式讀取文件，需要使用方指定字符編碼集！否則會出現(xiàn)亂碼問題。而 RandomAccessFile并未提供按照字符方式讀取文件的 API！

實際上 RandomAccessFile 提供了 getChar 方式讀取字符，但是默認(rèn)情況下 getChar 使用 JDK默認(rèn)的字符編碼： 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 秒，遠(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 + ": 時間:" + stopWatch.getTotalTimeSeconds());
}

輸出 文件行數(shù):150000: 時間:69.956510667

為什么性能如此差呢？通過查看源碼可以知道 RandomAccessFile 按行讀取時，是通過調(diào)用 read native 方法，每次讀取 1 個字符，如果該字符為換行符，那么則視為一行數(shù)據(jù)。

當(dāng)文件數(shù)據(jù)量較大時，每次僅讀取 1 個字符，會導(dǎo)致大量的系統(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è)務(wù)邏輯： 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é)果的字符長度和預(yù)期不一致 為什么呢？

由于文件內(nèi)容編碼方式為 UTF-8即不定長編碼字符集，讀取文件指定的緩沖區(qū)大小無法嚴(yán)格保證恰好讀取完整的字符，會存在半讀問題。

String str = new String(byteBuffer.array()); 這種轉(zhuǎn)換方式存在亂碼問題！

我重新生成了一個純中文文件，文件內(nèi)容為 4600 個字符，其中換行符 64 個，中文字符4536 個！按照如上錯誤的代碼讀取文件結(jié)果顯示，存在亂碼問題，字符總數(shù)也是錯誤的（輸出4725個，多于正確值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 + ": 時間:" + 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 長度，當(dāng)讀取到 1022 時發(fā)現(xiàn)剩余字符無法完全讀取，還剩 2 個字節(jié)未完全讀取，則將 1022 和 1023 兩個字節(jié)數(shù)據(jù)拷貝到 0 和 1，并且設(shè)置 position 為 2，那么當(dāng)下一次 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 的亂碼問題

一開始我認(rèn)為 ByteBuffer的 getChar 方法能按照字符讀取文件，然后經(jīng)過測試后，發(fā)現(xiàn) getChar 會遇到亂碼問題。

getChar 在解碼時，使用了 java char 基礎(chǔ)數(shù)據(jù)類型的編碼集 UTF-16，按固定長度 2 個字節(jié)進(jìn)行解碼！

無論文件的字符編碼是 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，當(dāng)存在換行符時，則拼接為一行

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)存的性能應(yīng)該強于堆內(nèi)存，然而事與愿違！

在代碼示例中，需要將 ByteBuffer 中的字節(jié)數(shù)組轉(zhuǎn)換為 CharBuffer，因此必須逐個字節(jié)地讀取 ByteBuffer。這正是性能下降的主要原因。

在 HeapByteBuffer 中，get 方法用于獲取指定的字節(jié)，通過 array[i] 的數(shù)組下標(biāo)方式進(jìn)行訪問，因而性能非常好。

然而，在 DirectByteBuffer 中，讀取指定字節(jié)時無法使用數(shù)組下標(biāo)直接訪問數(shù)據(jù)，而是通過調(diào)用 Unsafe.getByte 方法來實現(xiàn)。由于 Unsafe.getByte 是一個 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ù)更耗費資源。大多數(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)鍵代碼解讀

當(dāng)前位置和映射長度

相比 HeapByteBuffer ，MappedByteBuffer處理文件讀取要更復(fù)雜！channel.map 方法需要指定文件映射開始點和映射長度，需要有一個指針 position 標(biāo)識當(dāng)前讀取的位置，映射長度使用 mappedSize 標(biāo)識。

映射長度可以是固定長度嗎？不能，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 需要處理半讀問題，否則會出現(xiàn)亂碼問題。HeapByteBuffer 可以使用 compact 方法將未讀取的數(shù)據(jù)拷貝到緩沖區(qū)頭部，從而解決半讀問題。

然而每次 map 方法新創(chuàng)建一個 MappedByteBuffer，它不可以多次復(fù)用，所以對 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，當(dāng)存在換行符時，則拼接為一行

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)存方式相同。