史上最全零拷贝总结

有理唔理

已于 2024-09-02 18:16:06 修改

阅读量984

点赞数 1

分类专栏： java基本知识文章标签： java 网络 kafka netty

于 2023-03-30 20:52:18 首次发布

本文链接：https://blog.csdn.net/LSKCGH/article/details/129866080

版权

java基本知识专栏收录该内容

4 篇文章 0 订阅

订阅专栏

一、传统方式下消息读取发送

很多应用程序在发送文件时，可以等价为进行如下的系统调用

File.read(file, buf, len);
Socket.send(socket, buf, len);

例如消息中间件 Kafka 就是这个应用场景，从磁盘中读取一批消息后原封不动地写入网卡（NIC，Network interface controller）进行发送。

在没有任何优化技术使用的背景下，操作系统为此会进行 4 次数据拷贝，以及 4 次上下文切换，如下图所示：

如果没有优化，读取磁盘数据，再通过网卡传输的场景性能比较差：

4 次 copy：

CPU 负责将数据从磁盘搬运到内核空间的 Page Cache 中；
CPU 负责将数据从内核空间的 Socket 缓冲区搬运到的网络中；
CPU 负责将数据从内核空间的 Page Cache 搬运到用户空间的缓冲区；
CPU 负责将数据从用户空间的缓冲区搬运到内核空间的 Socket 缓冲区中。

4 次上下文切换：

read 系统调用时：用户态切换到内核态；
read 系统调用完毕：内核态切换回用户态；
write 系统调用时：用户态切换到内核态；
write 系统调用完毕：内核态切换回用户态。

我们不免发出抱怨：

CPU 全程负责内存内的数据拷贝还可以接受，因为效率还算可以接受，但是如果要全程负责内存与磁盘、网络的数据拷贝，这将难以接受，因为磁盘、网卡的速度远小于内存，内存又远远小于 CPU；
4 次 copy 太多了，4 次上下文切换也太频繁了。

二、DMA 参与下的数据拷贝

DMA：Direct Memory Access ，它可以独立地直接读写系统内存，不需要 CPU 介入

DMA 技术很容易理解，本质上，DMA 技术就是我们在主板上放一块独立的芯片。在进行内存和 I/O 设备的数据传输的时候，我们不再通过 CPU 来控制数据传输，而直接通过 DMA 控制器（DMA Controller，简称 DMAC）。这块芯片，我们可以认为它其实就是一个协处理器（Co-Processor）。

比如说，我们用千兆网卡或者硬盘传输大量数据的时候，如果都用 CPU 来搬运的话，肯定忙不过来，所以可以选择 DMAC。而当数据传输很慢的时候，DMAC 可以等数据到齐了，再发送信号，给到 CPU 去处理，而不是让 CPU 在那里忙等待。

注意，这里面的“协”字。DMAC 是在“协助”CPU，完成对应的数据传输工作。在 DMAC 控制数据传输的过程中，我们还是需要 CPU 的进行控制，但是具体数据的拷贝不再由 CPU 来完成。

原本，计算机所有组件之间的数据拷贝（流动）必须经过 CPU，如下图所示：

现在，DMA 代替了 CPU 负责内存与磁盘以及内存与网卡之间的数据搬运，CPU 作为 DMA 的控制者，如下图所示：

但是 DMA 有其局限性，DMA 仅仅能用于设备之间交换数据时进行数据拷贝，但是设备内部的数据拷贝还需要 CPU 进行，例如 CPU 需要负责内核空间数据与用户空间数据之间的拷贝（内存内部的拷贝），如下图所示：

上图中的 read buffer 也就是 page cache，socket buffer 也就是 Socket 缓冲区。

三、零拷贝技术

3.1 什么是零拷贝技术？

零拷贝技术是一个思想，指的是计算机执行操作时，CPU 不需要先将数据从某处内存复制到另一个特定区域。

可见，零拷贝的特点是 CPU 不全程负责内存中的数据写入其他组件，CPU 仅仅起到管理的作用。但注意，零拷贝不是不进行拷贝，而是 CPU 不再全程负责数据拷贝时的搬运工作。如果数据本身不在内存中，那么必须先通过某种方式拷贝到内存中（这个过程 CPU 可以不参与），因为数据只有在内存中，才能被转移，才能被 CPU 直接读取计算。

零拷贝技术的具体实现方式有很多，例如：

sendfile
mmap
splice
直接 Direct I/O

不同的零拷贝技术适用于不同的应用场景，下面依次进行 sendfile、mmap、splice, Direct I/O 的分析。

3.2 sendfile

sendfile 的应用场景是：用户从磁盘读取一些文件数据后不需要经过任何计算与处理就通过网络传输出去。此场景的典型应用是消息队列。

在传统 I/O 下，正如第一节所示，上述应用场景的一次数据传输需要四次 CPU 全权负责的拷贝与四次上下文切换。

sendfile 主要使用到了两个技术：

DMA 技术；
传递文件描述符代替数据拷贝

利用 DMA 技术

sendfile 依赖于 DMA 技术，如下图所示：

利用 DMA 技术减少 2 次 CPU 全程参与的拷贝

DMA 负责磁盘到内核空间中的 Page cache（read buffer）的数据拷贝以及从内核空间中的 socket buffer 到网卡的数据拷贝。

整个流程：DMA拷贝2次，CPU拷贝1次，用户空间和内核空间切换2次。

传递文件描述符代替数据拷贝

传递文件描述可以代替数据拷贝，这是由于两个原因：

page cache 以及 socket buffer 都在内核空间中；
数据传输过程前后没有任何写操作。

利用传递文件描述符代替内核中的数据拷贝

注意事项：只有网卡支持 SG-DMA（The Scatter-Gather Direct Memory Access）技术才可以通过传递文件描述符的方式避免内核空间内的一次 CPU 拷贝。这意味着此优化取决于 Linux 系统的物理网卡是否支持（Linux 在内核 2.4 版本里引入了 DMA 的 scatter/gather -- 分散/收集功能，只要确保 Linux 版本高于 2.4 即可）。

由于 sendfile 仅仅对应一次系统调用，而传统文件操作则需要使用 read 以及 write 两个系统调用。

正因为如此，sendfile 能够将用户态与内核态之间的上下文切换从 4 次降到 2 次。

sendfile 系统调用仅仅需要两次上下文切换

另一方面，我们需要注意 sendfile 系统调用的局限性。如果应用程序需要对从磁盘读取的数据进行写操作，例如解密或加密，那么 sendfile 系统调用就完全没法用。这是因为用户线程根本就不能够通过 sendfile 系统调用得到传输的数据。

整个流程：DMA拷贝2次，CPU拷贝0次，用户空间和内核空间切换2次。

3.3 mmap

mmap 即 memory map，也就是内存映射。

mmap 是一种内存映射文件的方法，即将一个文件或者其它对象映射到进程的地址空间，实现文件磁盘地址和进程虚拟地址空间中一段虚拟地址的一一对映关系。实现这样的映射关系后，进程就可以采用指针的方式读写操作这一段内存，而系统会自动回写脏页面到对应的文件磁盘上，即完成了对文件的操作而不必再调用 read、write 等系统调用函数。相反，内核空间对这段区域的修改也直接反映用户空间，从而可以实现不同进程间的文件共享。如下图所示：

mmap 也是一种零拷贝技术，其 I/O 模型如下图所示：

利用 mmap() 替换 read()，配合 write() 调用的整个流程如下：

用户进程调用 mmap()，从用户态陷入内核态，将内核缓冲区映射到用户缓存区；
DMA 控制器将数据从硬盘拷贝到内核缓冲区；
mmap() 返回，上下文从内核态切换回用户态；
用户进程调用 write()，尝试把文件数据写到内核里的套接字缓冲区，再次陷入内核态；
CPU 将内核缓冲区中的数据拷贝到的套接字缓冲区；
DMA 控制器将数据从套接字缓冲区拷贝到网卡完成数据传输；
write() 返回，上下文从内核态切换回用户态。

整个流程：DMA拷贝2次，CPU拷贝1次，用户空间和内核空间切换4次。

可以发现此种方案避免了内核空间和用户空间之间的数据拷贝工作，但是在内核空间内部还是会有一次数据拷贝的过程，而且cpu还是会有从内核空间和用户空间的切换过程。

3.4 splice

splice函数的作用是将两个文件描述符之间建立一个管道,然后将文件描述符的引用传递过去,这样在使用到数据的时候就可以直接通过引用指针访问到具体数据。过程如下:

第一步:通过DMA传输将文件复制到内核页缓冲区

第二步:通过splice函数在页缓冲区和socket缓冲区之间建立管道,并将文件描述符的引用指针发送给socket缓冲区

第三步:网卡通过DMA传输根据文件描述符的指针直接访问数据

如下图示：

整个过程中：DMA拷贝2次、CPU拷贝0次、内核空间和用户空间切换2次

可以看出通过slice函数传输数据时同样可以实现CPU的零拷贝

3.5 Direct I/O

Direct I/O 即直接 I/O。其名字中的“直接”二字用于区分使用 page cache 机制的缓存 I/O。

缓存文件 I/O：用户空间要读写一个文件并不直接与磁盘交互，而是中间夹了一层缓存，即 page cache；
直接文件 I/O：用户空间读取的文件直接与磁盘交互，没有中间 page cache 层。

“直接”在这里还有另一层语义：其他所有技术中，数据至少需要在内核空间存储一份，但是在 Direct I/O 技术中，数据直接存储在用户空间中，绕过了内核。

Direct I/O 模式如下图所示：

Direct I/O 示意图

此时用户空间直接通过 DMA 的方式与磁盘以及网卡进行数据拷贝。

Direct I/O 的读写非常有特点：

Write 操作：由于其不使用 page cache，所以其进行写文件，如果返回成功，数据就真的落盘了（不考虑磁盘自带的缓存）；
Read 操作：由于其不使用 page cache，每次读操作是真的从磁盘中读取，不会从文件系统的缓存中读取。

Direct I/O 的优缺点：

优点：

Linux 中的直接 I/O 技术省略掉缓存 I/O 技术中操作系统内核缓冲区的使用，数据直接在应用程序地址空间和磁盘之间进行传输，从而使得自缓存应用程序可以省略掉复杂的系统级别的缓存结构，而执行程序自己定义的数据读写管理，从而降低系统级别的管理对应用程序访问数据的影响。
与其他零拷贝技术一样，避免了内核空间到用户空间的数据拷贝，如果要传输的数据量很大，使用直接 I/O 的方式进行数据传输，而不需要操作系统内核地址空间拷贝数据操作的参与，这将会大大提高性能。

缺点：

由于设备之间的数据传输是通过 DMA 完成的，因此用户空间的数据缓冲区内存页必须进行 page pinning（页锁定），这是为了防止其物理页框地址被交换到磁盘或者被移动到新的地址而导致 DMA 去拷贝数据的时候在指定的地址找不到内存页从而引发缺页错误，而页锁定的开销并不比 CPU 拷贝小，所以为了避免频繁的页锁定系统调用，应用程序必须分配和注册一个持久的内存池，用于数据缓冲。
如果访问的数据不在应用程序缓存中，那么每次数据都会直接从磁盘进行加载，这种直接加载会非常缓慢。
在应用层引入直接 I/O 需要应用层自己管理，这带来了额外的系统复杂性。

四、应用案例

4.1 java中的应用

Java的应用程序经常会遇到数据传输的场景,在Java NIO包中就提供了零拷贝机制的实现,主要是通过NIO包中的FileChannel实现，FileChannel提供了transferTo和transferFrom方法,都是采用了调用底层操作系统的sendfile函数来实现的CPU零拷贝机制。

public class ChannelTransfer {
    public static void main(String[] argv) throws Exception {
        String files[]=new String[1];
        files[0]="D://db.txt";
        catFiles(Channels.newChannel(System.out), files);
    }

    private static void catFiles(WritableByteChannel target, String[] files)
            throws Exception {
        for (int i = 0; i < files.length; i++) {
            FileInputStream fis = new FileInputStream(files[i]);
            FileChannel channel = fis.getChannel();
            channel.transferTo(0, channel.size(), target);
            channel.close();
            fis.close();
        }
    }
}

通过 FileChannel 的 transferTo() 方法将文件数据传输到 System.out 通道，接口定义如下：

public abstract long transferTo(long position, long count, WritableByteChannel target) throws IOException;

几个参数也比较好理解，分别是开始传输的位置，传输的字节数，以及目标通道；transferTo() 允许将一个通道交叉连接到另一个通道。

MappedByteBuffer

Java NIO 提供的 FileChannel 提供了 map() 方法，该方法可以在一个打开的文件和 MappedByteBuffer 之间建立一个虚拟内存映射。

MappedByteBuffer 继承于 ByteBuffer，类似于一个基于内存的缓冲区，只不过该对象的数据元素存储在磁盘的一个文件中。

调用 get() 方法会从磁盘中获取数据，此数据反映该文件当前的内容，调用 put() 方法会更新磁盘上的文件，并且对文件做的修改对其他阅读者也是可见的。

下面看一个简单的读取实例，然后再对 MappedByteBuffer 进行分析：

public class MappedByteBufferTest {

    public static void main(String[] args) throws Exception {
        File file = new File("D://db.txt");
        long len = file.length();
        byte[] ds = new byte[(int) len];
        MappedByteBuffer mappedByteBuffer = new FileInputStream(file).getChannel().map(FileChannel.MapMode.READ_ONLY, 0,
                len);
        for (int offset = 0; offset < len; offset++) {
            byte b = mappedByteBuffer.get();
            ds[offset] = b;
        }
        Scanner scan = new Scanner(new ByteArrayInputStream(ds)).useDelimiter(" ");
        while (scan.hasNext()) {
            System.out.print(scan.next() + " ");
        }
    }
}

主要通过 FileChannel 提供的 map() 来实现映射，map() 方法如下：

public abstract MappedByteBuffer map(MapMode mode,
                                         long position, long size)
        throws IOException;

分别提供了三个参数，MapMode，Position 和 Size，分别表示：

MapMode：映射的模式，可选项包括：READ_ONLY，READ_WRITE，PRIVATE。
Position：从哪个位置开始映射，字节数的位置。
Size：从 Position 开始向后多少个字节。

重点看一下 MapMode，前两个分别表示只读和可读可写，当然请求的映射模式受到 Filechannel 对象的访问权限限制，如果在一个没有读权限的文件上启用 READ_ONLY，将抛出 NonReadableChannelException。

PRIVATE 模式表示写时拷贝的映射，意味着通过 put() 方法所做的任何修改都会导致产生一个私有的数据拷贝并且该拷贝中的数据只有 MappedByteBuffer 实例可以看到。

该过程不会对底层文件做任何修改，而且一旦缓冲区被施以垃圾收集动作（garbage collected），那些修改都会丢失。

4.2 Kakfa中的应用

Kafka 作为一个消息队列，涉及到磁盘 I/O 主要有两个操作：

producer 向 Kakfa 发送消息，Kakfa 负责将消息以日志的方式持久化落盘；
Consumer 向 Kakfa 进行拉取消息，Kafka 负责从磁盘中读取一批日志消息，然后再通过网卡发送。

Kakfa 服务端接收 producer的消息并持久化的场景下使用 mmap 机制，能够基于顺序磁盘 I/O 提供高效的持久化能力，使用的 Java 类为 java.nio.MappedByteBuffer。

Kakfa 服务端向 Consumer 发送消息的场景下使用 sendfile 机制，这种机制主要两个好处：

sendfile 避免了内核空间到用户空间的 CPU 全程负责的数据拷贝；
sendfile 基于 Page Cache 实现，因此如果有多个 Consumer 在同时消费一个主题的消息，那么由于消息一直在 page cache 中进行了缓存，因此只需一次磁盘 I/O，就可以服务于多个 Consumer。

使用 mmap 来对接收到的数据进行持久化，使用 sendfile 从持久化介质中读取数据然后对外发送是一对常用的组合。

4.3 netty中的零拷贝机制

Netty作为NIO的高性能网络通信框架,同样也实现了零拷贝机制,不过和操作系统的零拷贝机制则不是一个概念。

Netty中的零拷贝机制体现在多个场景:

使用直接内存,在进行IO数据传输时避免了ByteBuf从堆外内存拷贝到堆内内存的步骤,而如果使用堆内内存分配ByteBuf的话,那么发送数据时需要将IO数据从堆内内存拷贝到堆外内存才能通过Socket发送
Netty的文件传输使用了FileChannel的transferTo方法,底层使用到sendfile函数来实现了CPU零拷贝
ByteBuf支持slice方法可以将ByteBuf分解成多个共享内存区域的ByteBuf,避免了内存拷贝

最后的最后，题主开通了公众号：有理唔理，欢迎关注一下，一起探讨技术与生活。

参考博客：聊聊零拷贝技术