第12讲 | Java有几种文件拷贝方式？哪一种最高效？

典型回答

Java 有多种比较典型的文件拷贝实现方式,例如
利用 java.io 类库，直接为源文件构建一个 FileInputStream 读取，然后再为目标文件构建一个 FileOutputStream，完成写入工作。

public static void copyFileByStream(File source, File dest) throws
        IOException {
    try (InputStream is = new FileInputStream(source);
         OutputStream os = new FileOutputStream(dest);){
        byte[] buffer = new byte[1024];
        int length;
        while ((length = is.read(buffer)) > 0) {
            os.write(buffer, 0, length);
        }
    }
 }

或者，利用 java.nio 类库提供的 transferTo 或 transferFrom 方法实现。

public static void copyFileByChannel(File source, File dest) throws
        IOException {
    try (FileChannel sourceChannel = new FileInputStream(source)
            .getChannel();
         FileChannel targetChannel = new FileOutputStream(dest).getChannel
                 ();){
        for (long count = sourceChannel.size() ;count>0 ;) {
            long transferred = sourceChannel.transferTo(
                    sourceChannel.position(), count, targetChannel);            sourceChannel.position(sourceChannel.position() + transferred);
            count -= transferred;
        }
    }
 }

当然，Java 标准类库本身已经提供了几种 Files.copy的实现。

对于 Copy 的效率，这个其实与操作系统和配置等情况相关，，总体上来说，NIO transferTo/From 的方式可能更快，因为它更能利用现代操作系统底层机制，避免不必要拷贝和上下文切换。

拷贝实现机制分析

用户态空间（User Space）和内核态空间（Kernel Space），这是操作系统层面的基本概念，操作系统内核、硬件驱动等运行在内核态空间，具有相对高的特权；而用户态空间，则是给普通应用和服务使用。

当我们使用输入输出流进行读写时，实际上是进行了多次上下文切换，比如应用读取数据时，先在内核态将数据从磁盘读取到内核缓存，再切换到用户态将数据从内核缓存读取到用户缓存。写入操作也是类似，仅仅是步骤相反。

image.png

这种方式会带来一定的额外开销，可能会降低 IO 效率。

而基于 NIO transferTo 的实现方式，在 Linux 和 Unix 上，则会使用到零拷贝技术，数据传输并不需要用户态参与，省去了上下文切换的开销和不必要的内存拷贝，进而可能提高应用拷贝性能。注意，transferTo 不仅仅是可以用在文件拷贝中，与其类似的，例如读取磁盘文件，然后进行 Socket 发送，同样可以享受这种机制带来的性能和扩展性提高。

image.png

Java IO/NIO 源码结构

Java 标准库也提供了文件拷贝方法（java.nio.file.Files.copy）

private static long copy(InputStream source, OutputStream sink)
      throws IOException

public static Path copy(Path source, Path target, CopyOption... options)
  throws IOException

public static long copy(InputStream in, Path target, CopyOption... options)
  throws IOException

public static long copy(Path source, OutputStream out) 
throws IOException

copy 不仅仅是支持文件之间操作，没有人限定输入输出流一定是针对文件。

public static Path copy(Path source, Path target, CopyOption... options)
    throws IOException
 {
    FileSystemProvider provider = provider(source);
    if (provider(target) == provider) {
        // same provider
        provider.copy(source, target, options);// 这是本文分析的路径
    } else {
        // different providers
        CopyMoveHelper.copyToForeignTarget(source, target, options);
    }
    return target;
}

copy 方法其实不是利用 transferTo，而是本地技术实现的用户态拷贝。

如何提高类似拷贝等 IO 操作的性能，有一些宽泛的原则：

• 使用缓存等机制，合理减少 IO 次数
• 使用 transferTo 等机制，减少上下文切换和额外io
• 尽量减少不必要的转换过程，比如编解码；对象序列化和反序列化

NIO Buffer

Buffer 是 NIO 操作数据的基本工具，Java 为每种原始数据类型都提供了相应的 Buffer 实现（布尔除外）。

image.png

Buffer 有几个基本属性：

• capcity，它反映这个 Buffer 到底有多大，也就是数组的长度
• position，要操作的数据起始位置。
• limit，相当于操作的限额。在读取或者写入时，limit 的意义不一样，
  -mark，记录上一次 postion 的位置，默认是 0，算是一个便利性的考虑，往往不是必须的。

Buffer 的基本操作：

• 我们创建了一个 ByteBuffer，准备放入数据，capcity 当然就是缓冲区大小，而 position 是 0，limit 默认就是 capcity 的大小。
• 当我们写入几个字节的数据时，position 就会跟着水涨船高，但是它不可能超过 limit 的大小。
• 如果我们想把前面写入的数据读出来，需要调用 flip 方法，将 position 设置为 0，limit 设置为以前的 position 那里。
• 如果还想从头再读一遍，可以调用 rewind，让 limit 不变，position 再次设置为 0。

Direct Buffer 和垃圾收集

Direct Buffer：如果我们看 Buffer 的方法定义，你会发现它定义了 isDirect() 方法，返回当前 Buffer 是否是 Direct 类型。这是因为Java 提供了堆内和堆外（Direct）Buffer，通过allocate 或者 allocateDirect 方法直接创建。

MappedByteBuffer：它将文件按照指定大小直接映为内存区域，当程序访问这个内存区域时将直接操作这块儿文件数据,省去了将数据从内核空间向用户空间传输的损耗。我们可以使用FileChannel.map创建 MappedByteBuffer,它本质上也是种 Direct Buffer。

Java 会尽量对 Direct Buffer 仅做本地 IO 操作，对于很多大数据量的 IO 密集操作，可...可能会带来非常大的性能优势，因为：

• Direct Buffer 生命周期内内存地址都不会再发生更改，进而内核可以安全地对其进行访问，很多 IO 操作会很高效。
• 减少了堆内对象存储的可能额外维护工作，所以访问效率可能有所提高。
• Direct Buffer 创建和销毁过程中，都会比一般的堆内 Buffer 增加部分开销，所以通常都建议用于长期使用，数据较大的场景。

DirectBuffer 不在堆上，所以 Xmx 之类参数，其实并不能影响 Direct Buffer 等堆外成员所使用的内存额度，我们可以这样设置：

-XX:MaxDirectMemorySize=512M

从参数设置和内存问题排查角度来看，这意味着我们在计算 Java 可以使用的内存大小的时候，不能只考虑堆的需要，还有 Direct Buffer 等一系列堆外因素。如果出现内存不足，堆外内存占用也是一种可能性。

大多数垃圾收集过程中，都不会主动收集 Direct Buffer,它的回收是通过Cleaner（一个内部实现）和幻象引用（PhantomReference)机制，对它的销毁往往要拖到 full GC 的时候，所以使用不当很容易导致OOM。

对于 Direct Buffer 的回收的几个建议：

• 在应用程序中，显式地调用 System.gc() 来强制触发.
• 在大量使用 Direct Buffer 的部分框架中，框架会自己在程序中调用释放方法，Netty 就是这么做的。
• 重复使用 Direct Buffer。

极客时间版权所有: https://time.geekbang.org/column/article/8393
极客时间版权所有: https://time.geekbang.org/column/article/8393
rticle/8393
极客时间版权所有: https://time.geekbang.org/column/article/8393
极客时间版权所有: https://time.geekbang.org/column/article/8393
极客时间版权所有: https://time.geekbang.org/column/article/8393
极客时间版权所有: https://time.geekbang.org/column/article/8393...
极客时间版权所有: https://time.geekbang.org/column/article/8393
极客时间版权所有: https://time.geekbang.org/column/article/8393

极客时间版权所有: https://time.geekbang.org/column/article/8393
极客时间版权所有: https://time.geekbang.org/column/article/8393