17370845950

协程是语言级轻量控制流机制，用于异步/生成器等场景；线程是OS级并发单元，负责真正并行。二者解决不同问题，需依任务性质协同使用。

协程不是线程，也不是线程的替代品——它们解决的是不同层面的问题。C++20 引入的协程是**语言级的轻量级控制流机制**，用于简化异步、生成器、状态机等场景；而线程是操作系统调度的**并发执行单元**，负责真正意义上的并行。选错模型会导致性能浪费、逻辑混乱或根本无法编译。

协程：用户态的“可暂停函数”

协程本质是一个可以多次挂起（suspend）和恢复（resume）的函数。它不绑定 OS 线程，没有栈切换开销，也不需要内核参与调度。一次协程调用可能在同一个线程内分多段执行，中间穿插其他协程或普通代码。

• 协程对象（如 std::coroutine_handle）只保存少量上下文（比如挂起点地址、局部变量地址），内存占用通常几十字节
• 挂起/恢复由程序员通过 co_await、co_yield、co_return 显式控制，行为完全可预测
• 常见用途：异步 I/O 封装（避免回调地狱）、range 生成器（generator）、状态机建模（如协议解析）

线程：OS 管理的独立执行流

线程由操作系统创建和调度，拥有独立栈（默认 1MB+）、寄存器状态、优先级和调度策略。多个线程可在多核上真正并行运行，但也带来同步开销（锁、原子操作）、竞态风险和上下文切换成本（微秒级，但高频时显著）。

• 适合 CPU 密集型任务（如图像处理、数值计算），或必须并行等待多个外部事件（如多路网络连接）
• 不能直接用 co_await 等待线程结束——需配合 std::jthread 或条件变量，否则容易死锁
• C++20 的 std::jthread 提供自动 join，但仍是重量级资源，不宜高频创建销毁

协同使用才是常态

实际项目中，协程与线程往往共存：用少量线程（如 IOCP 线程池或 epoll 循环线程）驱动大量协程。协程负责逻辑拆分，线程负责底层并行执行。

• 例如：一个网络服务用 4 个线程跑 event loop，每个连接对应一个协程；协程遇到 socket read 就挂起，让出线程给其他协程，数据就绪后由 event loop 恢复它
• 切忌在一个协程里调用阻塞 API（如 std::this_thread::sleep_for），这会卡住整个线程——应改用协程感知的定时器（如 asio::steady_timer）
• 协程内部可安全使用局部变量、引用、智能指针；但跨协程共享数据仍需线程安全措施（如 std::atomic 或 std::mutex）

怎么选？看任务性质

判断依据不是“要不要并发”，而是“是否需要并行执行”以及“控制流是否天然分段”。

• 需要同时跑多个 CPU 密集任务 → 用线程（或线程池）
• 单线程里要处理上百个异步请求、且每个请求逻辑复杂 → 用协程 + event loop
• 写一个返回迭代序列的函数（如遍历文件夹树）→ 用 generator 协程，比手写迭代器简洁得多
• 既要并行又要异步 → 线程池 + 协程（如 boost::asio::thread_pool + co_await async_read）

基本上就这些。协程不难学，但容易误当成“更轻的线程”来用；线程不难写，但滥用会导致扩展性瓶颈。C++20 协程不是银弹，它是帮你把“该串行的地方串行得更干净，该并行的地方并行得更可控”的工具。