Java NIO用通道传输大文件并控制缓冲的实现方法

Java NIO 传输大文件时，核心不是把缓冲区调到很大，而是让 FileChannel、ByteBuffer 和文件位置各自只负责一件事：通道负责文件读写，缓冲区控制单次搬运量，循环负责处理“本次只读写了一部分”的情况。文件到文件的直接复制还可以优先考虑 transferTo，但也要检查返回值。

官方文档：https://docs.oracle.com/en/java/javase/26/docs/api/java.base/java/nio/channels/FileChannel.html

FileChannel、ByteBuffer 与文件位置各自负责什么

FileChannel 是连接到文件的可定位通道，既能读取、写入，也能按显式位置读写。相对读写会推进通道当前位置；带 position 参数的读写则把位置写在调用里，适合需要明确偏移的场景。ByteBuffer 只描述这一小段字节的装载范围，不应该用一个超大缓冲区代替流式处理。

打开文件时先把意图写在选项里。复制场景通常是输入使用 READ，输出使用 CREATE、WRITE 和 TRUNCATE_EXISTING，这样重复执行时不会把旧文件尾部残留接到新内容后面。

用受控 ByteBuffer 循环完成文件复制

下面的实现把缓冲区固定为 1 MiB。读操作结束后，flip() 让 position 回到已读数据的起点；写操作可能没有一次消费完全部字节，所以用 while (buffer.hasRemaining()) 继续写。写完后用 clear() 复用同一块内存。

import java.io.IOException;
import java.nio.ByteBuffer;
import java.nio.channels.FileChannel;
import java.nio.file.Path;
import java.nio.file.StandardOpenOption;

public final class LargeFileCopy {
    private LargeFileCopy() {}

    public static void copy(Path source, Path target) throws IOException {
        // 复制时明确读写方向，并截断旧目标文件，避免尾部残留。
        try (FileChannel input = FileChannel.open(source, StandardOpenOption.READ);
             FileChannel output = FileChannel.open(target,
                     StandardOpenOption.CREATE,
                     StandardOpenOption.WRITE,
                     StandardOpenOption.TRUNCATE_EXISTING)) {
            ByteBuffer buffer = ByteBuffer.allocate(1024 * 1024); // 只限制单块内存
            while (input.read(buffer) != -1) {
                // 切到读模式；position 到 limit 之间才是刚读入的数据。
                buffer.flip();
                while (buffer.hasRemaining()) {
                    // write 可能只消费一部分，因此必须持续写到缓冲区为空。
                    output.write(buffer);
                }
                // 清空边界，复用这块缓冲区接收下一块文件内容。
                buffer.clear();
            }
        }
    }
}

这里没有把结果交给 close() 才“顺便完成”。循环结束代表输入读到末尾，输出缓冲区也已经写空；try-with-resources 只负责在正常和异常路径都关闭通道。若业务要求更强的崩溃恢复语义，可以在明确代价后考虑 output.force(false)，它不是普通复制的默认必选项。

用 transferTo 传输大文件并控制 position 与 count

当源文件和目标都是通道时，transferTo(position, count, target) 可以减少中间 Java 缓冲区的搬运。它返回本次实际传输的字节数，因此应把 position 向前推进，直到累计值达到目标 count。不同文件系统、目标通道和操作系统实现可能让一次调用少传一部分。

import java.io.IOException;
import java.nio.channels.FileChannel;

public final class ChannelTransfer {
    private ChannelTransfer() {}

    public static long transfer(FileChannel source, FileChannel target) throws IOException {
        long size = source.size();
        long position = 0;
        while (position 

transferTo 适合“文件通道到文件通道”的整段复制；如果目标是带背压的网络通道，仍要结合目标通道的可写语义和超时策略。它也不自动替你做校验和、断点记录或原子替换，完成传输后仍应由业务决定如何验收目标文件。

按任务选择缓冲读写还是通道传输

一个实用判断是：只要中间要解压、解密、改格式或统计内容，就保留 ByteBuffer 循环；只做原样搬运，再评估 transferTo。不要仅凭方法名推断一定更快，实际效果取决于文件系统、目标通道和部署环境。

大文件传输完成前后的检查清单

• 目标文件使用了正确的打开选项，重跑复制不会保留旧尾部。
• 每个 read、write 或 transferTo 的返回值都参与了循环判断。
• 异常路径也能关闭输入和输出通道；不要把通道交给多个无主的生命周期。
• 传输完成后比较源、目标大小；需要更高可信度时再比较摘要，而不是只看方法没有抛异常。

常见问题

ByteBuffer 越大，文件复制就一定越快吗？

不一定。更大的缓冲区会提高单次搬运量，也会增加内存压力和缓存竞争；应结合文件系统、并发数和实际测量选择容量。

为什么 transferTo 还要写循环？

API 返回的是本次实际传输量，可能小于请求的 count。只有累计 position 达到目标范围，才算完成当前区间。

FileChannel 关闭后，来源流还能继续用吗？

如果通道来自 FileInputStream、FileOutputStream 或 RandomAccessFile，关闭通道会关闭对应对象；要把它们视作同一资源生命周期管理。

小结：用 ByteBuffer 控制内存，用循环处理部分读写，用 transferTo 简化原样通道传输，再用明确的关闭和验收条件收尾，才是 Java NIO 传输大文件的稳定组合。