将大文件拆分为块

1. 为什么用单线程读取大文件就像一块一块搬砖

当你处理的大文件达到几十或上百 MB，甚至 GB 级别时，单线程读写很快就会成为瓶颈。一个线程无法承载全部负载：磁盘能够更快地提供数据，而程序处理不及。

即便是快速的 SSD，瓶颈也未必在磁盘，而是各种开销——上下文切换、缓冲区处理、内存中的数据转换。结果就是吞吐下降，而 CPU 其他内核却在闲置。

比如，你要统计一个巨大日志中的单词数量。如果顺序处理，单线程会一点点啃完文件，而你只能等待。若把文件分块并交给多个线程处理，速度会快得多：每个线程处理自己的部分，最终几乎可以把磁盘潜力吃满。

在实践中，这大致是这样的：在带宽为 2 GB/s 的 SSD 上，单线程读取只有大约 300–500 MB/s。如果并行读取——就能把设备的性能基本榨干。

2. Chunking——让文件为你高效工作

当文件大到无法整体高效处理时，最合理的做法就是把它拆成若干部分。这个技巧称为chunking（来自 chunk，即“块”）。思路很简单：将大文件划分为多个逻辑段，每个线程负责一个区段。

每个线程都知道自己从哪个偏移量（offset）开始以及何处结束。它仅读取自己的那一段，完成处理后再把结果汇总。

这种方式可以同时调动所有 CPU 内核，显著加速处理，尤其是在现代 SSD 或 NVMe 磁盘上。对于统计行数、文本搜索或统计聚合之类的任务，chunking 就像“增压器”——几乎不费力就能带来明显的加速。

如何选择 chunk 大小

chunk 大小有点像“吃饭的分量”：太小会切碎成渣、频繁切换；太大又难以“消化”。它取决于任务类型和机器的性能。

一般而言，每线程取 8–64 MB 的范围效果不错。多数情况下选 10–20 MB 左右即可，但不存在放之四海而皆准的数字——需要通过实验调优。关键是：块要足够大以减少线程切换开销，又不能大到把 CPU 缓存挤爆或占满内存。

如果处理的是文本——例如统计单词或查找匹配——务必避免在块边界把一行或一个词“截断”。通常的做法很简单：给相邻块做一点重叠，或把边界调整到最近的换行符处。这样既保持处理的准确性，结果也更干净、可预测。

3. 用于按位置访问的工具：FileChannel 和 MappedByteBuffer

FileChannel: Positioned IO

FileChannel 是 java.nio.channels 包中的类，支持底层文件操作，包括从文件的任意位置读写数据。

关键方法：

• position(long newPosition) —— 设置读/写位置（offset）。
• read(ByteBuffer dst, long position) —— 从指定位置开始把数据读入缓冲区（不会改变通道的当前位置）。
• write(ByteBuffer src, long position) —— 从指定位置把缓冲区数据写入文件。

示例：读取文件片段

try (FileChannel channel = FileChannel.open(Path.of("bigfile.txt"), StandardOpenOption.READ)) {
    long chunkSize = 16 * 1024 * 1024; // 16 MB
    long offset = 0;
    ByteBuffer buffer = ByteBuffer.allocate((int) chunkSize);
    int bytesRead = channel.read(buffer, offset);
    // buffer 包含文件的前 16 MB
}

优点：

• 可以从任意位置读/写。
• 适合并行处理：每个线程只处理自己的“块”。

MappedByteBuffer: Memory-mapped files

MappedByteBuffer 是一种特殊缓冲区，可以把文件的一部分“映射”（map）到内存。操作系统会负责在磁盘与内存之间按需调页。

工作方式：

• 你把文件片段映射到内存。
• 像访问缓冲区一样读写——操作系统按需加载相应页面。
• 无需显式调用 read/write——一切通过内存完成。

示例：

try (FileChannel channel = FileChannel.open(Path.of("bigfile.txt"), StandardOpenOption.READ)) {
    long chunkSize = 16 * 1024 * 1024; // 16 MB
    long offset = 0;
    MappedByteBuffer buffer = channel.map(FileChannel.MapMode.READ_ONLY, offset, chunkSize);
    // 现在 buffer 的行为类似字节数组，但数据会在访问时从磁盘按需读取
}

优点：

• 速度很高（尤其在 SSD 上）。
• 简单：像数组一样读写。

缺点：

• 使用虚拟内存——如果文件非常大，可能“占住”大量地址空间。
• 不易精细控制何时从内存中回收（缓冲区可能比预期驻留更久）。
• 对超大文件并不总是方便（32 位系统上超过 2–4 GB 会受限）。

4. 示例：并行读取并统计单词

来看一个任务：使用并行处理统计大型文本文件（比如 10 GB 的日志）中的单词数量。

步骤 1：把文件切成多个 chunk

• 获取文件大小：long fileSize = Files.size(path);
• 选择 chunk 大小，例如 16 MB。
• 为每个 chunk 计算偏移量：offset = chunkIndex * chunkSize;
• 最后一个 chunk 的大小可能更小。

步骤 2：为线程创建任务

• 为每个 chunk 创建一个 Callable<Integer>（或 Runnable），其职责：
  • 通过 FileChannel.read(ByteBuffer, offset) 或 MappedByteBuffer 打开并读取自己的文件片段。
  • 统计该片段中的单词数。
  • 返回结果（单词总数）。

步骤 3：通过 ExecutorService 启动任务

• 创建线程池：ExecutorService pool = Executors.newFixedThreadPool(N);
• 把任务提交到线程池：List<Future<Integer>> results = pool.invokeAll(tasks);
• 收集结果：对所有 Future 的返回值求和。

代码示例（简化版）：

import java.nio.*;
import java.nio.channels.*;
import java.nio.file.*;
import java.util.*;
import java.util.concurrent.*;

public class ParallelWordCount {
    public static void main(String[] args) throws Exception {
        Path path = Path.of("bigfile.txt");
        long fileSize = Files.size(path);
        int chunkSize = 16 * 1024 * 1024; // 16 MB
        int chunks = (int) ((fileSize + chunkSize - 1) / chunkSize);

        ExecutorService pool = Executors.newFixedThreadPool(Runtime.getRuntime().availableProcessors());
        List<Future<Integer>> results = new ArrayList<>();

        for (int i = 0; i < chunks; i++) {
            long offset = (long) i * chunkSize;
            long size = Math.min(chunkSize, fileSize - offset);

            results.add(pool.submit(() -> {
                try (FileChannel channel = FileChannel.open(path, StandardOpenOption.READ)) {
                    MappedByteBuffer buffer = channel.map(FileChannel.MapMode.READ_ONLY, offset, size);
                    byte[] bytes = new byte[(int) size];
                    buffer.get(bytes);
                    String text = new String(bytes);
                    // 重要：要正确处理 chunk 的边界，避免把一个词截成两半！
                    return countWords(text);
                }
            }));
        }

        int totalWords = 0;
        for (Future<Integer> f : results) {
            totalWords += f.get();
        }
        pool.shutdown();
        System.out.println("Total words: " + totalWords);
    }

    private static int countWords(String text) {
        // 最简单的方法：按空白分割，并过滤掉空字符串
        String[] words = text.split("\\s+");
        int count = 0;
        for (String w : words) {
            if (!w.isBlank()) count++;
        }
        return count;
    }
}

注意：在实际项目中需要小心处理 chunk 的边界，避免把一个词或一行切到两个线程中。通常会做一个很小的 overlap（例如 +100 字节），并相应地修正 chunk 的起止位置。

5. 总结与最佳实践

• 处理大文件时，采用分块（chunking）与并行处理。
• 使用 FileChannel 进行按位置访问，使用 MappedByteBuffer 进行内存映射文件访问。
• 通过实验选择 chunk 大小；参考 CPU 缓存和磁盘带宽。
• 谨慎处理 chunk 边界（尤其是文本场景）。
• 用于并行处理时，采用 ExecutorService 和线程池。
• 不要滥用线程数量：在 SSD 上通常 2–4 个线程就足够。
• 关注内存占用：MappedByteBuffer 可能占用大量虚拟内存。

6. 操作大文件与 chunking 的常见错误

错误 №1：把整个文件一次性读入内存。 在处理大文件时，这可能导致 OutOfMemoryError。应当改为分块读取。

错误 №2：错误地处理 chunk 边界。 如果切分文件时没有考虑到行或单词的边界，可能会把数据“撕裂”，从而导致最终结果不正确。

错误 №3：不合适的 chunk 大小。 chunk 太小会带来不必要的线程管理开销；太大又会低效地占用内存。

错误 №4：忘记关闭 FileChannel。 这会导致资源泄漏。请使用 try-with-resources 来确保通道被正确关闭。

错误 №5：线程数量过多。 线程太多会让磁盘响应不过来，性能不升反降。