Java FileChannel transferTo 为什么可能只传输部分字节

Java FileChannel.transferTo 返回的是本次实际传输的字节数，不保证一次调用就完成传入的 count。当源文件剩余不足、目标通道是非阻塞通道，或通道状态限制了本次传输时，返回值都可能小于请求值。可靠做法是用返回值推进 position，循环处理剩余部分，并为返回 0 的零进展情况设置明确的退出或重试策略。

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

先接受 transferTo 的部分传输契约

调用 transferTo(position, count, target) 时，Java API 只承诺尝试从指定文件位置读取最多 count 个字节，并返回实际传输数量。若文件从 position 开始没有足够字节，或目标通道无法立即接收完整数量，就会出现短传输。方法不会修改源 FileChannel 的当前 position，调用者应把传入的位置当作自己的进度。

用循环推进文件位置

文件复制最小实现要同时维护两个变量：已经处理到的绝对位置和仍需传输的数量。每次调用后使用返回值更新它们；不能因为第一次返回小于 count 就直接认为复制失败。

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

static void copyFully(FileChannel source, FileChannel target,
                      long start, long count) throws IOException {
    long position = start;
    long remaining = count;
    int zeroProgress = 0;

    while (remaining > 0) {
        // 返回值是本次实际传输量，不能直接使用 remaining 作为进度。
        long transferred = source.transferTo(position, remaining, target);
        if (transferred > 0) {
            position += transferred;
            remaining -= transferred;
            zeroProgress = 0;
            continue;
        }

        // 连续零进展时退出，避免在关闭或无空间目标上无限忙等。
        if (++zeroProgress >= 2) {
            throw new IOException("transferTo made no progress");
        }
    }
}

如果目标是明确的阻塞文件通道，短传输后通常继续循环即可；如果目标是非阻塞 SocketChannel，应把零进展交给选择器和可写事件，而不是在循环里连续调用。

按目标通道类型判断边界

返回值较小并不直接说明发生了错误。源文件长度、传入位置、目标通道的阻塞特性和关闭状态都要一起看：

特别要注意，count 是上限，不是“必须成功写满”的承诺。若业务需要完整文件，应把预期大小与最终累计传输量比较，而不是只检查有没有抛异常。

用文件位置和结果验收复制

当目标也是 FileChannel 时，可在循环结束后检查目标文件大小或目标通道位置，确认累计写入量等于预期。生产代码还应把源文件大小、起始位置、请求数量、累计传输量和异常原因写入结构化日志。图中的循环逻辑是静态说明，不代表某次本机运行结果。

如果目标通道不能稳定地按文件传输语义工作，或者需要精确处理背压，可以退回 ByteBuffer 的读写循环。那样代码更长，但每次 read、write 的进度和等待点更显式，适合复杂的非阻塞网络协议。

相关问题

transferTo 返回 0 一定是文件传完了吗？

不一定。源位置已到文件末尾时会没有数据；非阻塞目标暂时不可写时也可能零进展。要结合源文件大小和目标通道状态判断。

transferTo 会自动修改源文件通道位置吗？

不会。它按调用参数中的 position 读取，循环应显式维护自己的位置。