Java InputStream.transferTo 怎样复制字节流并处理异常

Java 里需要把一个 InputStream 的全部字节交给 OutputStream 时，InputStream.transferTo 是最小且清晰的写法。它会持续读取输入流并写入输出流，返回实际传输的字节数；但它不会替调用方关闭输入流或输出流，发生 IOException 时也可能已经有部分内容写出。

先分清 transferTo 的输入、输出和返回值

第一次看到这个方法时，最容易误判的是把它当成“复制完成并自动收尾”的高级工具。实际职责更窄：当前的 InputStream 读取字节，传给参数中的 OutputStream，方法返回一个 long 表示已经传输的字节数。成功返回时，输入流通常已经到达流尾；输入和输出流仍由调用方决定何时关闭。

这个边界很重要。输出流如果是文件，传输成功后还要由外层关闭；输出流如果是 HTTP 响应，是否关闭通常由框架或响应处理器负责。不要因为调用了 transferTo 就在方法内部随意关闭不属于自己的流。

用 try-with-resources 完成一次文件复制

文件复制场景里，输入和输出都是当前方法创建的资源，可以统一交给 try-with-resources。下面的示例把返回值记下来，只有方法正常返回后才把目标文件视为完整复制结果：

import java.io.IOException;
import java.nio.file.Files;
import java.nio.file.Path;

public class StreamCopy {
    public static long copy(Path source, Path target) throws IOException {
        // 输入和输出都由当前方法创建，因此由 try-with-resources 统一关闭。
        try (var in = Files.newInputStream(source);
             var out = Files.newOutputStream(target)) {
            // transferTo 返回已经写入输出流的字节数，不代表业务文件已持久化到备份系统。
            long copied = in.transferTo(out);
            // 让缓冲输出流在离开资源块前完成提交；这里的 out 仍归当前方法管理。
            out.flush();
            return copied;
        }
    }
}

这里的 flush 不是为了替代关闭，而是把输出流中尚未下沉的数据尽快交给底层。离开资源块时仍会执行关闭。如果 transferTo 或 flush 抛出异常，调用方拿到的是失败，而不是一个可以放心使用的“半成品复制结果”。

IOException 发生后为什么不能继续复用原流

传输并不是一个不可分割的事务。读取输入或写入输出都可能在中途失败，所以异常发生时，输入流可能还没有到达末尾，输出端也可能已经落下部分字节。对普通文件来说，最稳妥的做法是关闭相关流、删除不完整的临时文件，再由上层决定是否重试。

public static long copyAtomically(Path source, Path target) throws IOException {
    Path temp = target.resolveSibling(target.getFileName() + ".part");
    try (var in = Files.newInputStream(source);
         var out = Files.newOutputStream(temp)) {
        // 只有 transferTo 和 flush 都成功，临时文件才有资格进入下一步替换。
        long copied = in.transferTo(out);
        out.flush();
        Files.move(temp, target, java.nio.file.StandardCopyOption.REPLACE_EXISTING);
        return copied;
    } catch (IOException failure) {
        // 失败文件可能只写了一部分，清理动作本身失败时保留原始异常。
        try {
            Files.deleteIfExists(temp);
        } catch (IOException cleanupFailure) {
            failure.addSuppressed(cleanupFailure);
        }
        throw failure;
    }
}

临时文件不是 transferTo 的要求，而是把“部分写入”隔离开的工程选择。对网络响应或进程输出则不能擅自删除远端结果，应该把失败向上返回，并让调用方决定重连、取消或记录失败。

响应流和进程流要重新确认关闭责任

如果输入流来自 HTTP 客户端响应，通常应在响应对象规定的生命周期内读取并关闭；不要把响应体复制完就误认为连接一定已经由当前方法正确回收。若输出流来自框架提供的响应对象，也不要在业务方法里关闭它，除非框架明确要求这样做。

如果输入流来自 Process.getInputStream()，传输完成或失败后要关闭进程输出流，并根据业务需要等待进程结束；标准输出和标准错误还可能需要分别消费，否则子进程可能因管道写满而停住。transferTo 只解决当前字节通道的复制，不替代进程生命周期管理。

常见问题

transferTo 会自动关闭 InputStream 和 OutputStream 吗？

不会。它只负责读取和写入，关闭责任由创建或拥有这些流的调用方承担。

返回字节数等于目标文件最终大小吗？

只有在传输和后续 flush 都成功、目标文件没有被其他逻辑修改时，二者才适合比较。异常发生后返回值不会作为成功结果交给调用方。

IOException 后能不能从原位置继续调用 transferTo？

不要把它当成可靠的断点续传接口。失败可能发生在读写任一侧，流和目标内容的状态都需要重新确认；文件场景更适合关闭并从临时文件重新开始。