零拷贝 Zero-copy

零复制（英语：Zero-copy；也译零拷贝）技术是指计算机执行操作时，CPU不需要先将数据从某处内存复制到另一个特定区域。这种技术通常用于通过网络传输文件时节省CPU周期和内存带宽。

原理

操作系统某些组件（例如驱动程序、文件系统和网络协议栈）若采用零复制技术，则能极大地增强了特定应用程序的性能，并更有效地利用系统资源。通过使CPU得以完成其他而非将机器中的数据复制到另一处的任务，性能也得到了增强。另外，零复制操作减少了在用户空间与内核空间之间切换模式的次数。

举例来说，如果要读取一个文件并通过网络发送它，传统方式下每个读/写周期都需要复制两次数据和切换两次上下文，而数据的复制都需要依靠CPU。通过零复制技术完成相同的操作，上下文切换减少到两次，并且不需要CPU复制数据。

零复制协议对于网络链路容量接近或超过CPU处理能力的高速网络尤为重要。在这种网络下，CPU几乎将所有时间都花在复制要传送的数据上，因此将成为使通信速率低于链路容量的瓶颈。

硬件实现

最早的实现为IBM OS/360，其中一个程序可以指示通道子系统从一个文件或设备复制数据块到另一处，无需先转移数据。

实现零复制的软件通常依靠基于直接存储器访问（DMA）的复制，以及通过内存管理单元（MMU）的内存映射。这些功能需要特定硬件的支持，并通常涉及到特定存储器的对齐。

一种较新的方式为使用异构系统架构（HSA），便于CPU和GPU以及其他处理器传递指针。这需要CPU和GPU使用统一地址空间。

程序访问

数种操作系统都通过特定API支持文件的零复制。

Linux内核通过各个系统调用支持零复制，例如sys/socket.h的sendfile、sendfile64以及splice。它们部分在POSIX中指定，因此也存在于BSD内核或IBM AIX中，部分则是Linux内核API中独有。

Microsoft Windows 通过 TransmitFile API 支持零复制。

Java输入流可以通过java.nio.channels支持零复制。FileChannel的transferTo()方法也可以支持零复制（如果底层操作系统支持）

远程直接内存访问（RDMA）协议深度依赖零复制技术。

“Zero-copy” describes computer operations in which the CPU does not perform the task of copying data from one memory area to another.

从WIKI的定义中，我们看到“零拷贝”是指计算机操作的过程中，CPU不需要为数据在内存之间的拷贝消耗资源。而它通常是指计算机在网络上发送文件时，不需要将文件内容拷贝到用户空间（User Space）而直接在内核空间（Kernel Space）中传输到网络的方式。

zerocopy技术的目标就是提高IO密集型JAVA应用程序的性能。在本文的前面部分介绍了：IO操作需要数据频繁地在内核缓冲区和用户缓冲区之间拷贝，而zerocopy技术可以减少这种拷贝的次数，同时也降低了上下文切换(用户态与内核态之间的切换)的次数。

当需要传输的数据远远大于内核缓冲区的大小时，内核缓冲区就会成为瓶颈。

zero copy减少copy，通常意义上的copy，会存在多次copy，减少这些copy实现本质上的一次copy。但受限于内核的支持并未能完全的消除copy。

file -> socket 的传输，从逻辑上说，仅需要一次read，加一次write，也就是一次copy，但目前的以cpu+mem为center的架构，无法直接设备间传输 —— 这里可能不严谨。

file —(DMA)—> kernel-page-buffer —-(read)—->user-space-buffer

—-(write)—> kernel-socket-buffer—(DMA)—> Network interface

传统 IO 读写有两种方式

• IO 中断
• DMA

传统 IO 流程

DMA(Direct Memory Access，直接存储器访问) 是所有现代电脑]的重要特色，它允许不同速度的硬件装置来沟通，而不需要依赖于[CPU的大量中断负载。

跟IO中断模式相比，DMA模式下，DMA就是CPU的一个代理，它负责了一部分的拷贝工作，从而减轻了CPU的负担。 DMA的优点就是：中断少，CPU负担低。

mmap 实现 zero-copy

什么是mmap，这种技术直接把pageCache映射到了用户态的内核空间这种就省去了CPU copy 部分。在 Linux 中，减少拷贝次数的一种方法是调用 mmap() 来代替调用 read，程序调用如下：1 tmp_buf = mmap(file, len); 2 write(socket, tmp_buf, len);

首先，应用程序调用了 mmap() 之后，数据会先通过 DMA 拷贝到操作系统内核的缓冲区中去。接着，应用程序跟操作系统共享这个缓冲区，这样，操作系统内核和应用程序存储空间就不需要再进行任何的数据拷贝操作，这时用户可以直接对数据进行加工。应用程序调用了 write() 之后，操作系统内核将数据从原来的内核缓冲区中拷贝到与 socket 相关的内核缓冲区中,此处两个内核区的缓冲区间的copy是CPU copy,从操作系统角度这已经是zero-copy因为数据没有在内核与用户空间进行copy。接下来，数据从内核 socket 缓冲区拷贝到协议引擎中去。当有大量数据要传输，这种操作会有一个比较好的效率。凡是都有两面性，mmap在使用的时候要注意文件共享带来的问题。

mmap(内存映射)是一个比sendfile昂贵但优于传统I/O的方法。

通过mmap实现的零拷贝I/O进行了4次用户空间与内核空间的上下文切换，以及3次数据拷贝。其中3次数据拷贝中包括了2次DMA拷贝和1次CPU拷贝。明显，它与传统I/O相比仅仅少了1次内核空间缓冲区和用户空间缓冲区之间的CPU拷贝。这样的好处是，我们可以将整个文件或者整个文件的一部分映射到内存当中，用户直接对内存中对文件进行操作，然后是由操作系统来进行相关的页面请求并将内存的修改写入到文件当中。我们的应用程序只需要处理内存的数据，这样可以实现非常迅速的I/O操作。

sendfile 实现 zero-copy

先来遐想一个场景，如果1.3中应用程序仅仅是读了文件，原封不动的发了出去，那么系统可以直接把上图中页缓存中数据给到Socket缓冲区就行了，甚至直接不要socket 缓冲区，直接把页缓冲区的内容发给网卡。那么linux 系统低级版本就是前一种做法，高级版本支持了后一种做法。

高级sendFile 数据传输,没有数据拷贝到socket缓冲区。取而代之的是只有相应的描述符信息会被拷贝到相应的socket缓冲区当中。该描述符包含了两方面的信息：1)页缓存的内存地址；2)页缓存的偏移量。DMA gather copy根据socket缓冲区中描述符提供的位置和偏移量信息直接将内核空间缓冲区中的数据拷贝到协议引擎上。 这种高级操作是需要硬件支持的。

Zero-Copy&Sendfile()

Linux 2.1版本内核引入了sendfile函数，用于将文件通过socket传送。 sendfile(socket, file, len); 该函数通过一次系统调用完成了文件的传送，减少了原来 read/write方式的模式切换。此外更是减少了数据的copy，sendfile的详细过程图2所示：

通过sendfile传送文件只需要一次系统调用，当调用 sendfile时： 1。首先通过DMA copy将数据从磁盘读取到kernel buffer中 2。然后通过CPU copy将数据从kernel buffer copy到sokcet buffer中 3。最终通过DMA copy将socket buffer中数据copy到网卡buffer中发送 sendfile与read/write方式相比，少了 一次模式切换一次CPU copy。但是从上述过程中也可以发现从kernel buffer中将数据copy到socket buffer是没必要的。

为此，Linux2.4内核对sendfile做了改进，如图3所示

改进后的处理过程如下： 1。DMA copy将磁盘数据copy到kernel buffer中 2。向socket buffer中追加当前要发送的数据在kernel buffer中的位置和偏移量 3。DMA gather copy根据socket buffer中的位置和偏移量直接将kernel buffer中的数据copy到网卡上。 经过上述过程，数据只经过了2次copy就从磁盘传送出去了。 （可能有人要纠结“不是说Zero－Copy么？怎么还有两次copy啊”，事实上这个Zero copy是针对内核来讲的，数据在内核模式下是Zero－copy的。话说回来，文件本身在瓷盘上要真是完全Zero－copy就能传送，那才见鬼了 呢）。 当前许多高性能http server都引入了sendfile机制，如nginx，lighttpd等。

Java NIO 中 FileChannel.transferTo(long position, long count, WriteableByteChannel target) 方法将当前通道中的数据传送到目标通道target中，在支持Zero-Copy的linux系统中，transferTo()的实现依赖于 sendfile()调用。

零拷贝给我们带来的好处

• 减少甚至完全避免不必要的CPU拷贝，从而让CPU解脱出来去执行其他的任务
• 减少内存带宽的占用
• 通常零拷贝技术还能够减少用户空间和操作系统内核空间之间的上下文切换

零拷贝完全依赖于操作系统。操作系统支持

真正的零拷贝

在Scatter/Gather DMA机制中，预先维护一个物理上不连续的块描述符链表，描述符中包含有数据的起始地址和长度。

数据传输时，只需要遍历链表，按序传输数据，全部完成后发起一次中断即可，效率比Block DMA要高。

借助于Scatter/Gather DMA，硬件可以直接从内核缓冲区中取得全部数据，不需要再从内核缓冲区向Socket缓冲区拷贝数据，这样就实现了真正的zero-copy。

为什么要有 DMA 技术

在没有 DMA 技术前，I/O 的过程是这样的：

• CPU 发出对应的指令给磁盘控制器，然后返回；
• 磁盘控制器收到指令后，于是就开始准备数据，会把数据放入到磁盘控制器的内部缓冲区中，然后产生一个中断；
• CPU 收到中断信号后，停下手头的工作，接着把磁盘控制器的缓冲区的数据一次一个字节地读进自己的寄存器，然后再把寄存器里的数据写入到内存，而在数据传输的期间 CPU 是无法执行其他任务的。

可以看到，整个数据的传输过程，都要需要 CPU 亲自参与搬运数据的过程，而且这个过程，CPU 是不能做其他事情的。

简单的搬运几个字符数据那没问题，但是如果我们用千兆网卡或者硬盘传输大量数据的时候，都用 CPU 来搬运的话，肯定忙不过来。

计算机科学家们发现了事情的严重性后，于是就发明了 DMA 技术，也就是直接内存访问（Direct Memory Access） 技术。

什么是 DMA 技术？简单理解就是，在进行 I/O 设备和内存的数据传输的时候，数据搬运的工作全部交给 DMA 控制器，而 CPU 不再参与任何与数据搬运相关的事情，这样 CPU 就可以去处理别的事务。

那使用 DMA 控制器进行数据传输的过程究竟是什么样的呢？下面我们来具体看看。

具体过程：

• 用户进程调用 read 方法，向操作系统发出 I/O 请求，请求读取数据到自己的内存缓冲区中，进程进入阻塞状态；
• 操作系统收到请求后，进一步将 I/O 请求发送 DMA，然后让 CPU 执行其他任务；
• DMA 进一步将 I/O 请求发送给磁盘； 磁盘收到 DMA 的 I/O 请求，把数据从磁盘读取到磁盘控制器的缓冲区中，当- 磁盘控制器的缓冲区被读满后，向 DMA 发起中断信号，告知自己缓冲区已满；
• DMA 收到磁盘的信号，将磁盘控制器缓冲区中的数据拷贝到内核缓冲区中，此时不占用 CPU，CPU 可以执行其他任务；
• 当 DMA 读取了足够多的数据，就会发送中断信号给 CPU；
• CPU 收到 DMA 的信号，知道数据已经准备好，于是将数据从内核拷贝到用户空间，系统调用返回；

可以看到， 整个数据传输的过程，CPU 不再参与数据搬运的工作，而是全程由 DMA 完成，但是 CPU 在这个过程中也是必不可少的，因为传输什么数据，从哪里传输到哪里，都需要 CPU 来告诉 DMA 控制器。

早期 DMA 只存在在主板上，如今由于 I/O 设备越来越多，数据传输的需求也不尽相同，所以每个 I/O 设备里面都有自己的 DMA 控制器。

传统的文件传输有多糟糕？

1
2

ssize_t read(int fd, void *buf, size_t count);
ssize_t write(int fd, const void *buf, size_t count);

首先，期间共发生了 4 次用户态与内核态的上下文切换，因为发生了两次系统调用，一次是 read() ，一次是 write()，每次系统调用都得先从用户态切换到内核态，等内核完成任务后，再从内核态切换回用户态。 其次，还发生了 4 次数据拷贝，其中两次是 DMA 的拷贝，另外两次则是通过 CPU 拷贝的

所以，要想提高文件传输的性能，就需要减少「用户态与内核态的上下文切换」和「内存拷贝」的次数。

如何实现零拷贝

mmap + write

1

void *mmap(void *addr, size_t length, int prot, int flags, int fd, off_t offset);

mmap() 系统调用函数会直接把内核缓冲区里的数据「映射」到用户空间，这样，操作系统内核与用户空间就不需要再进行任何的数据拷贝操作。

• 应用进程调用了 mmap() 后，DMA 会把磁盘的数据拷贝到内核的缓冲区里。接着，应用进程跟操作系统内核「共享」这个缓冲区；
• 应用进程再调用 write()，操作系统直接将内核缓冲区的数据拷贝到 socket 缓冲区中，这一切都发生在内核态，由 CPU 来搬运数据；
• 最后，把内核的 socket 缓冲区里的数据，拷贝到网卡的缓冲区里，这个过程是由 DMA 搬运的。

通过使用 mmap() 来代替 read()， 可以减少一次数据拷贝的过程。

但这还不是最理想的零拷贝，因为仍然需要通过 CPU 把内核缓冲区的数据拷贝到 socket 缓冲区里，而且仍然需要 4 次上下文切换，因为系统调用还是 2 次。

sendfile

在 Linux 内核版本 2.1 中，提供了一个专门发送文件的系统调用函数 sendfile()，函数形式如下：

1
2

#include <sys/socket.h>
ssize_t sendfile(int out_fd, int in_fd, off_t *offset, size_t count);

它的前两个参数分别是目的端和源端的文件描述符，后面两个参数是源端的偏移量和复制数据的长度，返回值是实际复制数据的长度。

首先，它可以替代前面的 read() 和 write() 这两个系统调用，这样就可以减少一次系统调用，也就减少了 2 次上下文切换的开销。

其次，该系统调用，可以直接把内核缓冲区里的数据拷贝到 socket 缓冲区里，不再拷贝到用户态，这样就只有 2 次上下文切换，和 3 次数据拷贝。

但是这还不是真正的零拷贝技术，如果网卡支持 SG-DMA（The Scatter-Gather Direct Memory Access）技术（和普通的 DMA 有所不同），我们可以进一步减少通过 CPU 把内核缓冲区里的数据拷贝到 socket 缓冲区的过程。

你可以在你的 Linux 系统通过下面这个命令，查看网卡是否支持 scatter-gather 特性：

1

ethtool -k eth0 | grep scatter-gather

于是，从 Linux 内核 2.4 版本开始起，对于支持网卡支持 SG-DMA 技术的情况下， sendfile() 系统调用的过程发生了点变化，具体过程如下：

• 第一步，通过 DMA 将磁盘上的数据拷贝到内核缓冲区里；
• 第二步，缓冲区描述符和数据长度传到 socket 缓冲区，这样网卡的 SG-DMA 控制器就可以直接将内核缓存中的数据拷贝到网卡的缓冲区里，此过程不需要将数据从操作系统内核缓冲区拷贝到 socket 缓冲区中，这样就减少了一次数据拷贝；

所以，这个过程之中，只进行了 2 次数据拷贝

这就是所谓的零拷贝（Zero-copy）技术，因为我们没有在内存层面去拷贝数据，也就是说全程没有通过 CPU 来搬运数据，所有的数据都是通过 DMA 来进行传输的。。

零拷贝技术的文件传输方式相比传统文件传输的方式，减少了 2 次上下文切换和数据拷贝次数，只需要 2 次上下文切换和数据拷贝次数，就可以完成文件的传输，而且 2 次的数据拷贝过程，都不需要通过 CPU，2 次都是由 DMA 来搬运。

所以，总体来看，零拷贝技术可以把文件传输的性能提高至少一倍以上。

JDK 中的 零拷贝

提供了一些类：DirectByteBuffer和FileChannel。

​ ByteBuffer主要有两种实现，一种是DirectByteBuffer， 一种是HeapByteBuffer。其中，DirectByteBuffer直接在堆外分配内存，底层是直接通过JNI调用操作系统的NIO系统调用，所以性能会比较高。而HeapByteBuffer是堆内内存，而且数据需要多一次拷贝，所以性能比较低。

FileChannel是Java NIO提供的用于复制文件的类，可以把文件复制到磁盘或者网络等。

​ map方法其实就是采用了操作系统中的内存映射方式，将内核缓冲区的内存和用户缓冲区的内存做了一个地址映射。

​ transferTo方法直接将当前通道内容传输到另一个通道，也就是说这种方式不会有内核缓冲区到用户缓冲区的读写问题。底层是sendfile系统调用。transferFrom方法同理。

Netty中也通过在FileRegion中包装了NIO的FileChannel.transferTo()方法实现了零拷贝。

MappedByteBuffer*

在调用FileChannel.map()时使用。 与DirectByteBuffer类似，这也是JVM堆外部的情况。 它基本上作为OS mmap()系统调用的包装函数，以便代码直接操作映射的物理内存数据。

HeapByteBuffer

在调用ByteBuffer.allocate()时使用。 它被称为堆，因为它保存在JVM的堆空间中，因此你可以获得所有优势，如GC支持和缓存优化。 但是，它不是页面对齐的，这意味着如果你需要通过JNI与本地代码交互时，比如写入网卡，写入磁盘，JVM将不得不复制到系统的页缓冲区空间。

DirectByteBuffer

在调用ByteBuffer.allocateDirect()时使用。 JVM在堆空间之外分配内存空间。 因为它不是由JVM管理的，所以你的内存空间是页面对齐的，不受GC影响，这使得它成为处理本地代码的完美选择。 然而，你要C程序员一样，自己管理这个内存，必须自己分配和释放内存来防止内存泄漏。

讲讲Netty的零拷贝？

所谓的 Zero-copy, 就是在操作数据时, 不需要将数据 buffer 从一个内存区域拷贝到另一个内存区域. 因为少了一次内存的拷贝, 因此 CPU 的效率就得到的提升

Netty 的 Zero-copy 体现在如下几个个方面:

• Netty 的接收和发送 ByteBuffer 采用 DIRECT BUFFERS，使用堆外直接内存进行 Socket 读写，不需要进行字节缓冲区的二次拷贝。如果使用传统的堆内存（HEAP BUFFERS）进行 Socket 读写，JVM 会将堆内存 Buffer 拷贝一份到直接内存中，然后才写入 Socket 中。相比于堆外直接内存，消息在发送过程中多了一次缓冲区的内存拷贝。
• Netty 提供了 CompositeByteBuf 类, 它可以将多个 ByteBuf 合并为一个逻辑上的 ByteBuf, 避免了各个 ByteBuf 之间的拷贝. 通过 wrap 操作, 我们可以将 byte[] 数组、ByteBuf、ByteBuffer等包装成一个 Netty ByteBuf 对象, 进而避免了拷贝操作.
• ByteBuf 支持 slice 操作, 因此可以将 ByteBuf 分解为多个共享同一个存储区域的 ByteBuf, 避免了内存的拷贝.
• 通过 FileRegion 包装的 FileChannel.tranferTo 实现文件传输, 可以直接将文件缓冲区的数据发送到目标 Channel, 避免了传统通过循环 write 方式导致的内存拷贝问题.

Kafka 的零拷贝

事实上，Kafka 这个开源项目，就利用了「零拷贝」技术，从而大幅提升了 I/O 的吞吐率，这也是 Kafka 在处理海量数据为什么这么快的原因之一。

如果你追溯 Kafka 文件传输的代码，你会发现，最终它调用了 Java NIO 库里的 transferTo

如果 Linux 系统支持 sendfile() 系统调用，那么 transferTo() 实际上最后就会使用到 sendfile() 系统调用函数。

• NIO
• Zero Copy
• 磁盘顺序读写
• Queue数据结构的极致使用 非常优秀的机制就是DelayQueue机制

消息消费的时候

包括外部Consumer以及Follower 从partiton Leader同步数据，都是如此。简单描述就是：

Consumer从Broker获取文件数据的时候，直接通过下面的方法进行channel到channel的数据传输。

也就是说你的数据源是一个Channel,数据接收端也是一个Channel(SocketChannel),则通过该方式进行数据传输，是直接在内核态进行的，避免拷贝数据导致的内核态和用户态的多次切换。

总结