欢迎访问本站，持续更新中…
RSS

WikiFw 维基框架

Go 零拷贝的代价：从 io.Copy 到 sendfile，我踩了一个性能假象的坑

1 个月前 Go零拷贝sendfile性能优化

📅 2026年7月6日

上周在调一个文件传输服务的性能时遇到了一个奇怪的现象。服务本身逻辑很简单：接收客户端上传的文件，处理后存储到后端。压力测试的时候发现，一个 200MB 的文件传输，CPU 占用率跑到 65%，而磁盘 IO 和网络吞吐都只用了不到 40%。

第一反应是代码写得有问题。我开始逐段 profile，定位到的热点是 io.Copy——标准库提供的万能拷贝函数。

这其实不是第一次遇到了。之前写过类似服务的时候我也用过 io.Copy，但那时候并发量不大，从来没觉得它会是瓶颈。

Go 程序 profiling

问题出在哪

io.Copy 的工作原理是在用户态分配一个 32KB 的缓冲区，从 src 读到缓冲区，再从缓冲区写到 dst。这意味着一次数据流动至少要经历两次用户态拷贝：一次 Read 进入缓冲区，一次 Write 离开缓冲区。对于一个 200MB 的文件，这就是 400MB 的用户态内存拷贝，全部占用 CPU。

这个机制我在写第一版代码的时候知道，但没有把它当回事。我觉得 32KB 缓冲区的拷贝在现代 CPU 上应该很快——编译器的优化、CPU 的缓存预取，总能把这件事做得不差。

但 profile 数据告诉我不是这么回事。

我第一次的判断完全错了

我一直以为 io.Copy 在底层会检测 src 和 dst 是否实现了某些特殊接口（比如 io.ReaderFrom 或 io.WriterTo），如果实现了就走专门的优化路径。

这个假设有一半是对的：io.Copy 确实会检查 WriterTo 和 ReaderFrom 接口。问题在于，大部分标准库的网络连接类型（*net.TCPConn）虽然实现了这些接口，但底层仍然是走用户态缓冲区的内存拷贝，并没有真正到内核态的零拷贝。

也就是说，即使你传的是两个 *net.TCPConn，io.Copy 也帮不了你太多。

发现这个事实的时候我其实有点沉默——这不是调优问题，是整个假设错了。

sendfile 工作原理

然后我开始看零拷贝方案

Go 里实现真正的零拷贝，主要有三条路。

第一个想到的是 sendfile 系统调用。它允许数据直接从文件描述符传输到 socket，完全绕过用户态。Linux 2.6.33 之后就已经支持了，Go 标准库也在 internal/poll 包里有 sendfile 的封装。

我尝试了直接通过 golang.org/x/sys/unix 调用 Sendfile，把文件从磁盘通过 sendfile 发送到 TCP 连接上。profile 结果确实好了很多——200MB 文件的 CPU 占用从 65% 降到了 22%。

但问题来了：sendfile 只适用于「文件 → socket」这个方向。如果你的场景是「socket → socket」（比如反向代理），sendfile 就用不了。

第二个方案是 splice，它可以在两个文件描述符之间零拷贝移动数据，不需要经过用户态。splice 比 sendfile 更通用，但它有一个坑：其中一端必须是管道（pipe）。

这里我走了弯路，而且走了一天多。我在两个 *net.TCPConn 之间用 splice 做数据搬运，先创建一个管道，把源 socket 的数据通过 splice 写到管道，再从管道通过另一个 splice 写到目标 socket。代码看起来是这样的：创建 pipe → splice(源 socket → pipe) → splice(pipe → 目标 socket)。

测试结果：CPU 占用确实下来了，但延迟涨了 3 倍。原因其实不复杂——管道本身有大小限制（默认 65536 字节），当数据吞吐超过这个限制时，splice 的调用次数急剧增加，每次 splice 都有上下文切换成本。

第三个方向是直接使用 io.Copy 的变体，但配合 TCP_CORK 和 TCP_NODELAY 的精细调参。这个我没深入——直觉告诉我这条路走不到真正的零拷贝。

最后我回去重新审视了项目需求：这个文件传输服务的主要场景是服务器之间的数据中转，大多数时候是「文件 → socket」。使用 sendfile 能满足 80% 的场景需求。「socket → socket」的 20% 场景，保留用 io.Copy 加上更大的缓冲区（从 32KB 提到 256KB），虽然达不到零拷贝，但足够应付。

性能数据对比

一个意外的发现

在测试 splice 方案时，我注意到一个奇怪的行为：当管道容量设为 65536 字节时，splice 每次搬运的平均数据量只有约 41000 字节，远不到管道的上限。

查了内核源码才发现，splice 从 socket 读取数据时，实际搬运量取决于 socket 接收缓冲区中当前可读的数据量，而不是管道剩余容量。即使管道还有 64000 字节的空位，如果 socket 缓冲区里只到了 41000 字节，splice 就只搬 41000。

这意味着通过调整管道大小来优化 splice 吞吐的思路，从一开始就是无效的。真正影响 splice 效率的参数是 socket 接收缓冲区的大小（rmem_default），而不是管道大小。

那两天其实挺消耗精力的。每次改完参数都想着这次总该行了吧，跑起来——延迟又涨了。机器的风扇一直全速转着，嗡嗡的声音从下午持续到半夜。

结尾

现在回头看，这次优化的核心结论其实很简单：在 Go 里实现零拷贝，不能用「标准库万能方案」的心态。不同的数据路径（文件→socket、socket→socket、文件→文件）对应完全不同的系统调用策略。sendfile 最适合「文件→socket」，splice 适合「socket→socket」但在低延迟场景下受限，而 io.Copy 虽然 CPU 开销大，却是最通用的 fallback。

不完美，远不完美。最理想的方案当然是所有数据路径都能走零拷贝。但工程上，你总是选那个 80% 场景最优的方案，然后为剩下的 20% 准备一个虽然慢但能用的兜底。

后来我一直在想，如果从一开始就认真读过 Go 标准库的 io.Copy 源码，也许那一个下午就不需要浪费来验证那些不靠谱的假设了。

关于维基框架

维基框架（Wiki Framework）是一套面向复杂业务场景的轻量级开发框架，支持多语言、多协议、多部署形态。适用于企业级应用开发、微服务架构、云原生部署等场景。