jvm - 为什么 java.nio.FileChannel transferTo() 和 transferFrom() 更快？？？它使用DMA吗？

Question

为什么在某些 JVM/OS 组合上 java.nio.FileChannel transferTo() 和 transferFrom() 比逐字节传输(基于流或使用 ByteBuffer)更快？？？

这些方法是否使用直接内存访问 (DMA) 而不是为每个字节传输发出中断请求 (IRQ)？

Answer 1

Do these methods use direct memory access (DMA) as opposed to issuing interrupt requests (IRQ) for each byte transfer?

具体以实际实现为准，不要求使用任何特定机制。 transferTo 的文档中暗示了这一点(重点是我的):

This method is potentially much more efficient than a simple loop that reads from this channel and writes to the target channel. Many operating systems can transfer bytes directly from the filesystem cache to the target channel without actually copying them.

“可能”、“很多”...所以无法保证。

假设使用该方法可能更有效是有道理的，即使只是略微如此，因为您允许 JVM 快捷方式通过 native 代码(如果使用受支持的 channel 类型)。他们描述的“简单循环”的工作原理如下所示:

ByteBuffer buf = ByteBuffer.allocateDirect(BUF_SIZE);
while ( /* read more condition */ ) {
  source.read(buf);
  buf.flip();
  target.write(buf);
  buf.compact();
}

请注意，即使此代码段使用直接缓冲区，您仍然需要回到 Java 中进行缓冲区管理(读取、翻转、写入、压缩)。优化编译器可能能够省略其中的一些，但它可能不会。

但是，使用transferTo/transferFrom 将由 JVM 决定如何传输字节。如果平台对这种传输有原生支持，它可以在不创建中间缓冲区的情况下执行此操作。如果没有这样的支持，the JVM can still implement a loop such as above .

示例:假设 SocketChannel 被告知通过 transferFrom 直接从 FileChannel 读取数据。最近读取了 FileChannel，其内容在操作系统文件缓存中。 SocketChannel 可以直接指向操作系统文件缓存并从那里开始传输，而不是读取字节并将其复制到缓冲区中。至少消除了一轮复制。

现在进一步假设套接字 (A) 实际上连接到某个其他本地进程，例如使用一种称为 SocketChannel B 的管道。当 B 开始读取它从 A 获得的内容时，它实际上可能直接从操作系统文件缓存。如果 B 只是使用 transferTo 到另一个 channel ......你明白了。