—— 从快递站的排队说起

你有没有在快递站排过队？

想象一下这样的场景：你走进快递站，前面有十个人在等。传统的方式是——你站在那里，盯着前面人的后脑勺，一步一挪，直到轮到你。

这就是epoll的工作方式。它很高效，比早期的"每个人都要问一遍"（select/poll）聪明多了。但它仍然有一个根本问题：你还是要等。

现在想象另一种方式：你走进快递站，留下你的取件码，然后去喝咖啡。快递准备好了，他们打电话叫你。

这就是io_uring。

一、Linux内核的一次顿悟

2019年，Linux内核5.1发布了一个新东西，叫io_uring。

它的发明者Jens Axboe说了一句话，道出了它的本质：

"我们能不能让I/O操作像函数调用一样简单？"

在传统的方式里，当你想读一个文件，你要：

1. 告诉内核"我要读"
2. 等着内核读完
3. 内核告诉你"读完了"

这中间有无数的上下文切换、状态检查、等待循环。

io_uring说：别这么麻烦了。

它创造了两个环形队列（ring buffer）：

• 提交队列（SQ）：你把想做的操作扔进去
• 完成队列（CQ）：内核把做完的操作扔出来

就像快递站的取件窗口和通知喇叭。你放下取件码就走，喇叭响了再来拿。

不需要等待。不需要反复询问。不需要上下文切换。

二、PHP的协程困境

PHP程序员有一个长期的痛点：异步编程。

PHP是同步的。当你写：

{{LATEX:0}}stats = {{LATEX:1}}stats['event_loop_lag_ms'];     // 当前延迟
echo {{LATEX:2}}stats['event_loop_lag_avg_ms']; // 平均延迟

这是什么意思？

想象你是一个餐厅经理。你想知道服务员有没有在偷懒。你可以看：

• 顾客点完菜多久才上菜？
• 最慢的有多慢？
• 平均速度如何？

事件循环延迟就是这个指标。它告诉你：从事件发生到被处理，隔了多久。

如果延迟很高，说明你的事件循环被阻塞了——可能是某个协程在做CPU密集型操作，或者某个I/O操作没有正确异步化。

这是性能调优的金矿。

七、哲学层面：我们在追求什么？

让我们退后一步，看看这些技术更新背后的哲学。

从epoll到io_uring，我们在追求什么？

消除等待。

计算机科学里有一个残酷的事实：CPU比I/O快一百万倍。

当你让CPU等一个磁盘读取，就像让爱因斯坦去等一杯咖啡——这是巨大的浪费。

协程、io_uring、异步I/O——所有这些技术，本质上都是在解决同一个问题：

如何让CPU永远有事情做，而不是等待？

OpenSwoole 26.2.0的更新，把这个理念推向了新的高度。

八、实际应用：什么时候用io_uring？

不是所有场景都需要io_uring。

适合的场景：

• 大量文件I/O（日志、缓存、静态文件服务）
• 高并发网络服务
• 需要极致性能的应用

不适合的场景：

• 简单的CRUD应用（epoll已经够快了）
• 内核版本低于5.13（multishot poll不支持）
• 没有liburing的系统

启用方式：

// 运行时启用io_uring
Co::set(['reactor_type' => OPENSWOOLE_IO_URING]);

// 启用Fiber上下文（推荐同时启用）
Co::set(['use_fiber_context' => true]);

编译时需要：

--enable-io-uring

九、结语：技术的诗意

费曼曾经说过：

"物理学就像性爱：当然，它可以带来实际的结果，但那并不是我们为什么做它的原因。"

技术也是如此。

我们追求io_uring，不只是因为它更快。我们追求它，是因为它优雅。

它用一个简单的环形队列，解决了复杂的异步问题。它让内核和用户空间之间的通信，变得像函数调用一样自然。

这就是好的技术——它让复杂的事情变得简单。

下次当你在PHP里写：

go(function() {
    $content = file_get_contents('bigfile.txt');
    // 处理文件...
});

记住，在底层，有一个环形队列在默默工作。你的请求被放进去，内核在后台处理，完成后再通知你。

你没有等待。你去喝咖啡了。

这就是io_uring的魔法。

参考

• OpenSwoole 26.2.0 Release Notes
• io_uring: The Future of Linux I/O
• PHP Fiber RFC

"最好的代码是从不运行的代码。第二好的是在内核里运行的代码。"

—— 某位疲惫的PHP程序员