零拷贝技术原理与实践

[toc]

# 引言

在现代计算机系统中，高效的IO（输入/输出）操作对于系统整体性能至关重要。随着应用程序对数据处理需求的不断增长，如何减少CPU在IO操作中的开销，提高数据传输效率，成为系统设计中的重要课题。零拷贝（Zero-Copy）技术应运而生，成为解决这一问题的关键技术之一。

零拷贝技术通过减少或消除数据在内存中的拷贝次数，以及减少用户态与内核态之间的上下文切换，显著提升了IO操作的性能。本文将详细介绍零拷贝技术的工作原理及其在实际项目中的应用。

我是 sharkchili ，CSDN Java 领域博客专家，mini-redis的作者，我想写一些有意思的东西，希望对你有帮助，如果你想实时收到我写的硬核的文章也欢迎你关注我的公众号： 写代码的SharkChili 。因为近期收到很多读者的私信，所以也专门创建了一个交流群，感兴趣的读者可以通过上方的公众号获取笔者的联系方式完成好友添加，点击备注 "加群" 即可和笔者和笔者的朋友们进行深入交流。

# 详解零拷贝工作原理

# 传统的IO流程是什么样的

我们先简单了解一下文件读取的粗略流程，应用程序需要读取文件时，对应的流程为：

应用程序发起read读取请求。
系统内核将数据从硬盘加载到内核缓冲区。
内核缓冲区拷贝用户空间缓冲区。
应用程序基于用户缓冲区读取数据进行业务流程处理。

基于上述基础，我们在进行深入了解如下几个概念，这对我们了解传统IO流程的理解有着重要的作用：

内核态：内核态是操作系统内核运行的模式，当我们需要操作系统内核级别的特权指令(例如上文的read操作)，就需要切换为内核态。内核态具备操作系统的最高权限，可以访问计算机所有的硬件资源和数据。
用户态：和内核态相反，应用程序所处的模式也就是用户态，是应用程序运行的模式，在该模式下仅仅能执行普通指令，无法直接访问操作操作系统敏感数据和计算机硬件资源。
内核缓冲区：内核缓冲区可以理解为应用程序和外部存储介质数据的中介，即应用程序和外部存储介质或者网络socket交互的数据都会经由内核缓冲区进行中转。
用户缓冲区：提供于应用程序直接读写操作的内存空间，这也就意味着我们需要处理任何外部存储介质或者网络socket数据都必须加载到内核缓冲区应用程序才能进行进一步的操作。
磁盘空间缓冲区：磁盘缓冲区用于处理那些从磁盘中读取或者准备写入磁盘的数据的临时内存存储空间，它是一种对于磁盘I/O的优化策略，本质上就是通过内存高速的访问速度，减少读取磁盘数据的耗时，从而提高数据读写的执行性能。
PageCache：PageCache也就是我们所说的磁盘高速缓存，操作系统为了保证读写性能，用到了局部性原理，通俗来说也就是操作系统认为近期被读取的数据以及相邻的数据再次被访问的概率很高，于是这些读取过的数据以及相邻的数据都会缓存在PageCache中，当我们再次进行相同数据读取时，如果PageCache存在该数据则会直接返回，反之则会到外部存储介质读取。注意PageCache数据并非一直活跃于内存中，一旦内存空间被占满，由于缓存置换算法，某些长时间未被访问的PageCache就会被淘汰。

有了初步的认识我们就可以更加深入的去分析传统IO流程了，先来说说读的详细流程，对应的时序图如下所示，可以看到完整IO读流程为：

应用程序发起read调用，因为涉及系统内核的操作，所以需要进行一次模式切换，从用户态转为内核态。
内核通过外部存储介质或者网络socket发起读操作。
磁盘或者网络数据写入磁盘缓冲区。
内核将数据从磁盘缓冲区加载到内核缓冲区。
内核缓冲区将数据拷贝到用户缓冲区，提供应用程序处理。
完成上述操作后，再次进行模式切换，从内核态转为用户态。

同理我们再次给出传统IO的写入操作：

应用程序发起write调用，进行一次模式切换，从用户态转为内核态。
将数据从用户缓冲区写入内核缓冲区。
内核缓冲区将数据写入到磁盘缓冲区。
最终磁盘缓冲区数据被写入到磁盘或者网络套接字中。

# 解决传统IO性能瓶颈的思路有哪些

传统IO模式性能开销存在于以下三点：

整个数据的传输过程都需要CPU参与，在此过程期间CPU不能做其他事情。
因为数据需要经过内核缓冲区的缘故，导致发起IO调用时存在用户态到内核态模式上下文切换的开销。
数据传输时需要在用户缓冲区、内核缓冲区来回拷贝的开销，消耗了大量CPU时间片和内存带宽。

# mmap+write零拷贝

第一点本质上可以通过内存映射文件技术(Memory-mapped Files)解决。该技术通过将文件直接映射到用户空间的内存区域，使得应用程序可以直接访问文件数据，避免了数据在用户空间和内核空间之间的拷贝操作：

通过DMA进行数据写入时，也是一个道理，通过DMA将内核缓冲区数据写入至外部存储/socket：

再来聊聊第二点，针对用户态、内核态上下文切换的开销，我们可以通过内存映射文件技术(Memory-mapped Files)解决。该技术将文件直接映射到用户空间的内存区域，使得应用程序可以直接访问文件数据，避免了数据在用户空间和内核空间之间的拷贝操作，从而减少了上下文切换的开销：

# sendfile实现零拷贝

接下来就是第三点，针对直接文件传输，实际上Linux内核2.1及其以上版本提供sendfile内核函数，该函数可直接将文件数据从一个文件描述符传输到另一个文件描述符（如从文件到socket），减少了数据在内核缓冲区和用户缓冲区之间的拷贝操作，节省了一大部分拷贝的开销：

# sendfile更进一步的优化

实际上sendfile内核函数在Linux的2.4版本做了更进一步的优化，若网卡支持SG-DMA（Scatter-Gather DMA）技术的情况下，上一步将磁盘数据写入到内核缓冲区再通过CPU将磁盘数据拷贝到socket缓冲区的步骤可以省去，通过DMA控制器将数据直接写入到网卡，将写入的文件描述符和数据长度告知socket缓冲区，由此通过避免CPU参与，完成大文件的高效传输：

# splice实现零拷贝

除了sendfile，Linux还提供了splice系统调用，它可以在两个文件描述符之间移动数据，其中一个必须是管道描述符。splice通过在内核空间中直接移动数据，避免了用户空间和内核空间之间的数据拷贝，进一步提升了IO性能：

应用程序 → splice() → 管道缓冲区 → splice() → 目标文件描述符

splice特别适用于需要在文件和管道之间传输数据的场景，例如在网络服务器中将文件数据传输到网络套接字。

# 聊聊零拷贝技术在大型开源项目中的运用

# mmap+write技术的运用

对于mmap+write技术的运用，最典型的就是RocketMQ中MappedFile的init方法，可以看到它的mappedByteBuffer 就是通过map方法与内核缓冲区构成映射，实现尽可能少的数据拷贝提升数据读写性能：

private void init(final String fileName, final int fileSize) throws IOException {
	//封装文件信息
    this.fileName = fileName;
    this.fileSize = fileSize;
    this.file = new File(fileName);
    this.fileFromOffset = Long.parseLong(this.file.getName());
    boolean ok = false;
	
    ensureDirOK(this.file.getParent());

    try {
    	//与文件file的内核缓冲区数据构成映射，并将内核缓冲区数据地址信息封装到mappedByteBuffer 
        this.fileChannel = new RandomAccessFile(this.file, "rw").getChannel();
        this.mappedByteBuffer = this.fileChannel.map(MapMode.READ_WRITE, 0, fileSize);
       //......
    } catch (FileNotFoundException e) {
          //......
    } catch (IOException e) {
         //......
    } finally {
        if (!ok && this.fileChannel != null) {
            this.fileChannel.close();
        }
    }
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

从java开发者的角度来说，mmap+write技术在java中的实现有如下优缺点，先来说说优点：

通过内存映射减少了内核缓冲区和用户缓冲区来回拷贝的开销，提升程序读写效率。
对于小文件，这种方式即使频繁调用，效果也会比sendfile更好。

说完了优点，我们再来说说缺点：

MappedByteBuffer 一次只能映射2G的文件，超出则会抛出异常，这也是为什么RocketMQ的CommitLog日志文件大小为1G。
在网络传输过程中，内核缓冲区的数据仍然需要CPU进行拷贝，在某些场景下相较于sendfile会多消耗CPU资源。
mmap技术内存分配存在复杂的安全性控制，对于内存进行严格管控处理，避免JVM Crash问题。

# Kafka对于sendfile技术的运用

查看Kafka中FileRecords的writeTo方法可知，Kafka中partition leader到follower的消息同步和consumer拉取partition中的消息，都是直接通过transferFrom（底层就是通过sendfile实现）实现的：

// org.apache.kafka.common.record.FileRecords
    @Override
    public long writeTo(GatheringByteChannel destChannel, long offset, int length) throws IOException {
       	//......
        if (destChannel instanceof TransportLayer) {
            TransportLayer tl = (TransportLayer) destChannel;
            //调用transferFrom从channel中拉取数据到destChannel中
            bytesTransferred = tl.transferFrom(channel, position, count);
        } else {
        	//将channel数据写到destChannel中
            bytesTransferred = channel.transferTo(position, count, destChannel);
        }
        return bytesTransferred;
    }

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

这种方式实现的零拷贝可以很好的利用DMA方式，尽可能减少CPU的消耗，对于大块的文件传输，效率会高一些，但它也有着如下几个缺点：

就当前java的实现而言，它仅仅支持源为FileChannel传输到socketChannel，不支持源为socketChannel。
对于小文件传输，处理效率不如mmap方式，只能是BIO方式传输，不能使用NIO。

# 小结

零拷贝技术通过减少或消除数据在内存中的拷贝次数，以及减少用户态与内核态之间的上下文切换，显著提升了IO操作的性能。本文详细介绍了以下几种零拷贝技术：

mmap+write：通过内存映射文件技术，将文件直接映射到用户空间，避免了数据在用户空间和内核空间之间的拷贝。
sendfile：通过系统调用直接在内核空间中传输数据，避免了用户空间和内核空间之间的数据拷贝。
splice：通过管道在内核空间中传输数据，进一步减少了数据拷贝。

在实际应用中，不同的零拷贝技术适用于不同的场景：

对于小文件传输，mmap方式通常表现更好
对于大文件传输，sendfile方式通常表现更好
在网络传输中，sendfile可以更好地利用DMA技术，减少CPU消耗

通过合理选择和应用零拷贝技术，可以显著提升系统的IO性能，特别是在处理大量数据传输的场景中。

# 参考

编辑

上次更新: 2026/03/26, 01:05:31

← 从操作系统底层浅谈程序栈的高效性 CPU缓存一致性问题深度解析→