异步IO与响应式编程的性能价值及技术疑问

同步IO #

当需要执行读取IO操作时，对文件描述符发起read系统调用。CPU进入特权模式并执行内核代码，通过设备驱动请求设备获取数据，同时将当前线程置为BLOCKED状态。最终调度器启动，其他线程接管该线程原本运行的CPU核心。
设备自行处理请求，完成后触发CPU中断。中断处理程序执行内核代码，将线程状态置为READY（此处为大幅简化描述）。此后内核调度器运行时，该线程将获得调度机会。

异步IO #

发起系统调用，系统调用请求设备获取数据。与同步IO不同，此时不会修改线程状态，而是返回一个特殊标记表示数据尚未就绪，线程可继续执行。

通常不会直接调用这类系统调用，而是使用库提供的包装函数，该函数接收回调作为参数。库会生成一个线程，对所有调用的文件描述符进行select操作（如epoll、kqueue等）。当部分文件描述符可交互时，该线程会在工作线程池（运行事件循环/任务循环）中调度对应的回调。

若上述描述存在错误，欢迎指正！

1. 异步IO是否具备性能或资源层面的优势？ #

据我了解，相较于完整上下文切换，线程切换成本较低。若存在足够多的待处理任务，CPU仍能被充分利用（会调度其他线程）。

我认为可能的优势包括：

• 内存利用率：线程数量更少意味着内核中为栈和线程相关数据结构分配的内存更少。
• 调度开销：内核的线程调度逻辑可能较为复杂，减少线程可降低此类开销。

但我认为异步IO也可能存在性能损耗点：

• 系统调用总量更多：一次请求操作一次系统调用，等待结果时还需另一次。
• 回调需被调度到工作线程执行。
• 执行回调时跳转到任意位置可能破坏缓存一致性？

2. 将该理念进一步延伸的响应式编程/协程（所有代码以事件形式在工作线程运行）是否具备性能优势？ #

3. 我们为何要采用响应式编程？ #

在我看来，响应式编程在进程和线程这一已为开发者提供抽象的基础上，额外构建了一层抽象，带来了更多复杂度。
有时该模式看似合理，例如假设我们需要单独的UI线程。但在我看来，这本质上只是同步的替代方案——我们只需启动一个获取UI锁的线程即可实现相同效果。

我无法理解传统并发模型中的哪些不足催生了响应式编程框架。

恳请各位提供相关解释及参考资料。

内容的提问来源于stack exchange，提问作者Jan Undrych