协程适合IO密集型还是计算密集型任务？｜阿里巴巴后端开发面经解析

60 秒回答模板

面试中我会先给结论：协程天然更适合 IO 密集型任务，而不是单纯的计算密集型任务。协程的优势不在于让 CPU 算得更快，而在于当任务遇到网络请求、文件读写、数据库访问、远程调用等等待型操作时，可以在用户态主动让出执行权，由事件循环或运行时调度器切换到其他就绪协程。这样可以用较少线程承载大量并发连接，减少内核线程切换、栈内存和锁竞争成本。对于计算密集型任务，如果协程内部长时间执行纯计算且不主动让出，事件循环可能被阻塞，其他协程无法及时运行，系统吞吐和延迟都会变差。要发挥协程价值，底层 IO 最好是非阻塞 IO、异步 IO 或由运行时托管的阻塞调用；同时还要控制并发量、设置超时、限流和背压，避免把下游服务或内存打爆。如果确实有 CPU 密集型逻辑，应拆分小任务、定期让出、放到线程池或进程池，或者利用多核并行。简而言之，协程解决的是大量等待和调度成本问题，不是替代 CPU 并行能力的万能方案。

考点 基本结论

主线 用户态切换

易错点 误以为协程一定比线程快，忽略了任务类型和运行时实现。

深入解析

基本结论

协程更适合 IO 密集型任务。IO 密集型任务的瓶颈通常在等待外部资源，例如网络响应、数据库返回、文件读写或 RPC 调用，协程可以在等待期间挂起当前执行流，让同一线程继续处理其他就绪任务，从而提升并发利用率。

用户态切换

协程是用户态轻量级执行单元。相比操作系统线程，协程切换通常不需要陷入内核，保存和恢复的上下文更少，创建成本、栈成本和调度成本都更低。这个优势在海量连接、大量等待和短任务切换场景中最明显。

非阻塞前提

协程要发挥作用，底层等待最好是非阻塞 IO、异步 IO 或运行时能托管的阻塞机制。若协程内部调用真正阻塞线程的系统调用，整个调度线程会被卡住，事件循环或工作线程无法继续运行其他协程，协程优势会被抵消。

事件循环与恢复

事件循环负责监听 IO 就绪事件，运行时调度器负责把就绪协程放回执行队列。协程遇到 await、yield、异步 IO 或运行时封装的等待点时挂起，IO 完成后再恢复执行。理解这个挂起和恢复过程，才能解释为什么等待型任务收益更大。

CPU 任务限制

计算密集型任务的瓶颈在 CPU 周期。协程本身不增加核心数，也不能让一个核心同时执行多个纯计算任务；如果一个协程长时间占用 CPU，它可能让同一调度线程上的其他协程迟迟得不到执行，造成整体响应变慢。

多核利用

有些语言运行时会把协程调度到多个工作线程上，从而利用多核，但这依赖运行时调度、线程数量和任务是否可拆分并行。即便如此，协程只是任务组织方式，多核加速仍来自线程或进程级并行，而不是协程本身突破 CPU 限制。

背压控制

IO 密集型场景不能只追求创建更多协程。高并发请求需要连接池、队列长度、信号量、限流、熔断、超时和取消机制，否则大量挂起协程会把等待转化为内存堆积、下游拥塞和雪崩风险。协程降低的是调度成本，不会自动扩大数据库、RPC 服务或文件系统的容量。

适用边界

协程适合高并发网络服务、网关、聊天、RPC 聚合、批量数据库请求、爬取等等待多于计算的场景；不适合直接承载长时间加密、压缩、编解码、机器学习推理等纯 CPU 重负载，这些任务应进入线程池、进程池或专门计算服务。

工程判断

判断任务类型时要看耗时主要花在哪里。如果大部分时间在等待外部响应，协程收益明显；如果大部分时间在 CPU 火焰图顶部函数里消耗，就应优先考虑算法优化、并行计算、任务切分和资源隔离，而不是单纯增加协程数量。

易错点

误以为协程一定比线程快，忽略了任务类型和运行时实现。
把协程理解成多核并行计算工具，认为创建更多协程就能提升 CPU 吞吐。
在协程中直接使用阻塞式 IO 调用，导致调度线程被卡住。
只强调协程数量大，却不讨论连接池、超时、取消和背压。
忽略协作式调度的让出点，写出长时间不挂起的 CPU 循环。
把异步 IO、非阻塞 IO、协程三者混为一谈，无法说明它们如何配合。
没有区分语言运行时差异，例如有的协程由单线程事件循环承载，有的可调度到多工作线程。
认为协程能解决所有高并发问题，忽视下游容量、内存限制和系统稳定性。
面试回答只给结论，不解释阻塞、调度、上下文切换和 CPU 饱和之间的关系。

面试官追问

如果协程里调用了阻塞式数据库驱动，会发生什么？

如果运行时不能把这个阻塞调用转移到专门线程，当前调度线程会被卡住，同线程上的其他协程无法继续执行。结果是协程数量很多，但并发能力接近被阻塞线程限制。

协程和线程的上下文切换成本差异主要来自哪里？

线程切换通常由内核调度，涉及内核态切换、寄存器和调度状态保存，成本更高。协程切换多在用户态完成，只保存必要执行上下文，因此更轻，但也依赖运行时实现。

事件循环为什么害怕长时间 CPU 计算？

事件循环通常依赖单个或少量线程轮询事件并恢复任务。如果某个协程长时间纯计算不让出执行权，事件循环不能处理新的 IO 就绪事件，其他请求延迟会显著升高。

协作式调度和抢占式调度有什么区别？

协作式调度依赖任务在 await、yield 或安全点主动让出，调度开销低但怕长任务不让出；抢占式调度由系统或运行时强制打断任务，更公平但调度和同步成本更高。

如何控制十万个协程同时请求下游服务的压力？

需要设置连接池上限、信号量、队列长度、超时、取消、限流和熔断，并根据下游容量做背压。协程可以很多，但真正并发访问外部资源的数量必须受控。

CPU 密集型任务应该如何和协程架构结合？

可以把 CPU 重任务拆成小块并定期让出，或者投递到线程池、进程池、计算服务中执行。协程负责协调 IO 和任务编排，真正计算仍要依赖多核并行或算法优化。

如何判断线上接口瓶颈是 IO 等待还是 CPU 计算？

可以结合 CPU 使用率、线程状态、等待时间、外部依赖耗时、火焰图和调用链判断。大量时间在网络或数据库等待说明偏 IO，热点函数长期占 CPU 则说明偏计算。