关于协程效率的困惑：单CPU下协程为何比同步代码更高效？

你的假设前提存在偏差：文件处理并非纯CPU密集任务 #

你假设processFile是纯CPU计算型任务（比如仅对内存中的文件内容做运算），这种情况下单CPU下协程并发和同步串行的总耗时确实一致——CPU始终处于满负荷工作状态，没有空闲时间可利用。但真实的文件处理流程里，processFile通常包含大量IO操作：

• 从磁盘读取文件内容到内存
• 处理完成后将结果写入磁盘
  这些IO操作执行时，CPU是处于空闲状态的，这才是协程发挥效率优势的核心场景。

真实IO密集场景下的耗时对比 #

举个贴近实际的例子：
假设processFile的流程是：读文件（1秒，CPU空闲）→ 计算处理（1秒，CPU忙碌）→ 写文件（1秒，CPU空闲）

• 同步串行总耗时：(1+1+1)+(1+1+1) = 6秒
• 协程并发总耗时：读file1的1秒内，CPU可以启动file2的读取操作；file1读完成后进入计算阶段时，file2可能还在读取；最终总耗时约等于单个任务的总耗时（3秒），因为IO等待的时间被用来处理另一个任务了。

协程的核心优势：非阻塞挂起，避免CPU空转 #

协程的高效不是依赖“时间切片”（那是线程的内核态调度方式），而是用户态的非阻塞挂起：当一个协程遇到IO操作时，会主动让出CPU给其他协程执行，等IO操作完成后再恢复自身执行。这种调度的开销远小于线程的内核态切换，同时最大化利用了CPU的空闲时间。

哪怕是单CPU，只要任务存在IO等待环节，协程就能把原本浪费的CPU空闲时间利用起来，整体效率必然高于同步串行。只有当任务是纯CPU密集型时，单CPU下协程才不会比同步更快——但这种场景本来就不是协程的适用场景。

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