Java NIO FileChannel 怎么实现可恢复的大文件复制

大文件复制最怕的不是慢，而是复制到一半进程退出后只能从头再来。一个稳妥的做法是把最终文件和临时文件分开：用目标临时文件的长度作为可见进度，再用独立的 checkpoint 记录已经确认的偏移。Java NIO 的 FileChannel 负责按位置读写，任务重启后从安全偏移继续。

先把最终文件、临时文件和恢复点分开

建议使用三个路径：源文件 source.bin、临时文件 target.bin.part、恢复点 target.bin.checkpoint。最终文件不存在或保持旧版本，消费者不会读到半成品；临时文件保存已写入的数据，checkpoint 只保存一个字节偏移。

恢复时以 checkpoint 为主、以临时文件长度为辅：如果 checkpoint 大于临时文件长度，说明状态记录领先，不能直接跳过去；示例选择回退到临时文件长度，并把源文件大小固定在任务开始时，防止复制过程中源文件被追加。

用 FileChannel 按偏移处理短传输

transferTo(position, count, target) 不会改变源 channel 的当前位置，返回值才是实际写入量。因此循环变量必须用返回值递增；返回 0 时再做一次小块 ByteBuffer 兜底，避免某些文件系统或大文件场景下循环无法前进。

static void copyResumable(Path source, Path part, Path checkpoint) throws IOException {
    long sourceSize = Files.size(source); // 固定本次任务看到的源文件边界
    long partSize = Files.exists(part) ? Files.size(part) : 0L;
    long saved = readCheckpoint(checkpoint); // 读取上次已确认的偏移
    long offset = Math.min(saved, partSize); // 记录领先时回退到实际文件长度

    try (FileChannel in = FileChannel.open(source, StandardOpenOption.READ);
         FileChannel out = FileChannel.open(part, StandardOpenOption.CREATE,
                 StandardOpenOption.WRITE, StandardOpenOption.READ)) {
        if (in.size() 

上面的示例把“恢复”限定为单写入者任务。生产环境还应给 checkpoint 加校验和或任务 ID，防止另一份源文件误用旧恢复点；如果需要跨机器容灾，也不能把本地 force 当成远端存储的提交确认。

checkpoint 的顺序决定恢复是否安全

正确顺序是：写入临时文件 → 调用 out.force(false) → 写 checkpoint。若先写 checkpoint，进程恰好在文件数据落盘前崩溃，重启可能从一个实际上不存在的偏移继续，结果中间出现空洞或旧数据。

完成复制后再校验和替换

不要因为 current == sourceSize 就直接认为复制成功。还要确认临时 channel 的 size() 等于任务开始时记录的源文件大小，并根据业务需要比较摘要。通过后再使用 Files.move 替换目标文件；ATOMIC_MOVE 是否可用取决于文件系统，失败时应明确记录并采用同一文件系统内的安全替换策略。

如果任务需要支持暂停，可以把“已 force 的偏移”作为唯一外部状态；如果需要并发分段复制，则每个分段都要有独立范围和校验，不能让多个线程同时推进同一个普通 channel 的共享位置。

常见问题

为什么不能只读取目标文件长度？

长度只说明文件有多少字节，不说明这些字节是否已经确认落盘；checkpoint 与 force 配合可以把恢复边界定义得更清楚。

transferTo 返回 0 是否代表复制完成？

不是。它只表示本次没有传输字节，可能与 channel 或文件系统状态有关；应避免死循环，并使用小块读取写入兜底。

什么时候应该删除 checkpoint？

只有临时文件长度校验通过且最终文件替换成功后删除。失败或中断时保留，下一次才有机会恢复。