1. 从“回调地狱”到“同步思维”为什么我们需要C20协程如果你写过网络服务、异步IO或者任何需要处理大量并发任务的C程序大概率对“回调地狱”这个词不陌生。层层嵌套的回调函数让代码逻辑支离破碎状态管理变得异常困难。后来我们有了std::async、std::future但它们更像是“一次性”的异步任务包装对于复杂的、需要暂停和恢复的异步流程依然力不从心。C20协程的引入正是为了解决这个问题——它允许我们以近乎同步的、线性的代码风格来编写高效的异步程序。简单来说协程是一种可以暂停执行并在之后恢复执行的函数。这个“暂停”不是被操作系统调度走的而是由函数自身主动让出的。想象一下你在读一本很厚的书每次读到一个关键情节需要查资料时你就在那一页夹个书签然后去查资料。查完资料后你不是从头开始读而是直接翻到书签的位置继续读下去。协程里的“暂停点”co_await就是那个书签而“恢复点”就是你夹书签的那一页。编译器会帮我们记住暂停时的所有局部变量状态就像书签记住了页码和阅读进度恢复时一切如初。这带来的最大好处是可读性和可维护性的飞跃。处理一个异步的HTTP请求你不再需要写一堆lambda回调而是可以写成这样线性的代码co_await 连接服务器(); auto data co_await 读取数据(); co_await 处理数据(data); co_await 发送响应();。每个co_await点函数都会优雅地暂停让出线程去处理其他任务等它等待的操作如网络IO完成后再回来继续。对于服务器开发这意味着可以用更少的线程甚至单线程承载更高的并发连接因为线程不再被阻塞的IO操作挂住而是在协程暂停期间去执行其他就绪的协程了。2. 核心概念拆解三驾马车与编译器魔法C20的协程标准并没有提供一个“开箱即用”的、像Pythonasyncio那样的完整框架。它提供的是一套底层的、用于构建异步框架的“乐高积木”。理解这套积木是灵活运用协程的关键。核心是三个新关键字和一套编译器生成的约定。2.1 关键字co_await,co_yield,co_return这三个关键字是协程函数的标志。只要函数体里出现了它们任何一个这个函数就是一个协程。编译器会对它进行特殊的处理。co_await这是最核心的操作符用于暂停协程等待某个“等待体”Awaitable完成。co_await expr;这里的expr必须是一个符合“Awaitable”概念的类型。当执行到co_await时协程会检查这个等待体是否需要暂停调用await_ready()。如果需要暂停则挂起协程并调用await_suspend()这个函数通常会安排一个在等待体完成时恢复协程的回调。当等待体完成比如一个异步读操作完成协程被恢复调用await_resume()获取结果然后继续执行。注意co_await并不直接与多线程相关。它只管理协程的暂停与恢复。如何调度在哪个线程恢复是由await_suspend的实现决定的。这是理解“协程是更轻量的用户态线程”的关键。co_yield用于生成器Generator模式。co_yield value;可以近似理解为co_await promise.yield_value(value);。它会将value返回给调用者并暂停协程。下次恢复时从co_yield之后继续执行。这是实现惰性求值序列如遍历容器、读取数据流的利器。co_return用于结束协程并返回一个最终值或void。它代替了普通的return。co_return expr;会调用promise.return_value(expr)对于非void或promise.return_void()然后进行协程的最终销毁流程。2.2 编译器生成的“脚手架”Promise与Coroutine Handle当你定义一个协程函数Task foo()时编译器会在背后做大量工作生成一个状态机。这个状态机的行为由两个核心类型控制Promise Type和Coroutine Handle。Promise对象这是协程的“控制中心”。编译器会为每个协程实例在堆上分配一个状态帧存储局部变量、暂停点等并在其中嵌入一个Promise对象。Promise类型定义了初始行为get_return_object()方法它返回给协程调用者的对象比如我们定义的Task。初始/最终挂起initial_suspend(),final_suspend()方法返回一个等待体决定协程开始和结束时是否立即挂起。异常处理unhandled_exception()方法。值传递yield_value(),return_void(),return_value()方法对应co_yield和co_return。 你的Task类通常会包含一个std::coroutine_handlepromise_type而这个promise_type就是你自定义的Promise类型。协程句柄Coroutine Handlestd::coroutine_handlepromise_type是一个不拥有所有权的指针指向协程的状态帧。通过它你可以恢复协程handle.resume()。销毁协程handle.destroy()。访问Promise对象handle.promise()。检查是否完成handle.done()。 句柄是手动管理协程生命周期的关键。通常我们的Task类会持有这个句柄并在析构时调用destroy()如果协程尚未完成来防止内存泄漏。下面这个极度简化的例子展示了这些部分是如何联系在一起的// 1. 定义Promise类型 struct MyPromise { // 协程的返回值类型 struct promise_type { // 调用协程时返回给外部的对象 MyPromise get_return_object() { return MyPromise{std::coroutine_handlepromise_type::from_promise(*this)}; } // 协程开始时不暂停 std::suspend_never initial_suspend() noexcept { return {}; } // 协程结束后暂停以便我们获取结果或处理善后 std::suspend_always final_suspend() noexcept { return {}; } void unhandled_exception() { std::terminate(); } void return_void() {} }; // 2. 返回值类型MyPromise持有一个句柄 std::coroutine_handlepromise_type handle_; MyPromise(std::coroutine_handlepromise_type h) : handle_(h) {} ~MyPromise() { if (handle_) handle_.destroy(); } }; // 3. 一个协程函数 MyPromise my_coroutine() { std::cout Coroutine started\n; co_await std::suspend_always{}; // 暂停点 std::cout Coroutine resumed\n; co_return; // 结束 } int main() { auto p my_coroutine(); // 此时协程执行到initial_suspend后遇到第一个co_await暂停 std::cout Coroutine suspended, now resume it\n; p.handle_.resume(); // 恢复协程它将打印Coroutine resumed然后执行final_suspend // main结束p析构如果协程未完成会调用destroy清理状态帧。 }这个例子虽然简单但包含了自定义Promise、句柄管理和手动恢复的完整流程。在实际的异步框架中co_await等待的不会是简单的suspend_always而会是封装了IO事件、定时器或其它异步操作的复杂等待体。3. 从零手搓一个最小化异步任务框架理解了原理我们动手实现一个最简单的Task异步框架。这个框架的目标是支持co_await一个简单的“延迟”操作并能链式调用。这能让你透彻理解Awaitable、Promise和调度是如何协作的。3.1 定义Awaitable封装异步操作首先我们定义一个最简单的异步操作等待一段时间。我们需要一个类型让co_await能够作用在它上面。这个类型必须实现三个函数await_ready,await_suspend,await_resume。#include chrono #include coroutine #include iostream #include thread #include functional // 一个简单的Awaitable在某个线程睡眠指定时间后恢复 struct SleepAwaitable { std::chrono::milliseconds duration; // 是否已经就绪如果时间为0则无需暂停。 bool await_ready() const noexcept { return duration.count() 0; } // 暂停协程。我们在这里启动一个定时器定时结束后恢复协程。 // handle 是当前协程的句柄 void await_suspend(std::coroutine_handle handle) const { // 注意这里为了简单直接在新线程睡眠然后恢复。 // 真实框架中这里应该将handle和定时事件注册到事件循环如io_uring, epoll。 std::thread([handle, dur duration]() mutable { std::this_thread::sleep_for(dur); handle.resume(); // 时间到恢复协程 }).detach(); // 分离线程简单演示。实际应用需要线程池管理。 } // 恢复时调用的函数返回值就是 co_await 表达式的结果。 void await_resume() const noexcept {} };这个SleepAwaitable就是一个符合规范的等待体。co_await SleepAwaitable{100ms}时如果时间大于0协程会暂停并启动一个后台线程计时计时结束后调用handle.resume()来恢复协程。3.2 定义Task与Promise类型接下来我们定义协程的返回值类型Task和它内部的promise_type。class Task { public: // 前置声明Promise类型 struct promise_type; // 协程句柄类型 using handle_type std::coroutine_handlepromise_type; struct promise_type { // 存储可能发生的异常 std::exception_ptr exception_; // 构造时直接返回Task对象该对象持有从当前promise创建的句柄。 Task get_return_object() { return Task{handle_type::from_promise(*this)}; } // 协程开始后立即挂起让调用者获得控制权决定何时开始执行。 // 这是“惰性启动”的常见模式。 std::suspend_always initial_suspend() noexcept { return {}; } // 协程结束后也挂起这样我们可以在Task析构前检查异常或获取结果。 std::suspend_always final_suspend() noexcept { return {}; } // 协程以co_return;结束 void return_void() noexcept {} // 捕获协程体内未处理的异常 void unhandled_exception() noexcept { exception_ std::current_exception(); } }; // Task对象持有一个协程句柄 explicit Task(handle_type handle) : handle_(handle) {} // 移动构造 Task(Task other) noexcept : handle_(std::exchange(other.handle_, nullptr)) {} // 禁止拷贝 Task(const Task) delete; Task operator(const Task) delete; ~Task() { // 如果句柄存在且协程未结束比如被异常销毁需要主动销毁状态帧。 if (handle_ !handle_.done()) { handle_.destroy(); } } // 恢复协程执行直到下一个暂停点或结束。 void resume() { if (handle_ !handle_.done()) { handle_.resume(); } } // 检查协程是否已执行完毕 bool is_done() const noexcept { return !handle_ || handle_.done(); } // 重新抛出协程内部捕获的异常如果有 void rethrow_if_exception() { if (handle_) { auto exc handle_.promise().exception_; if (exc) { std::rethrow_exception(exc); } } } private: handle_type handle_; };这个Task设计体现了几个关键点惰性启动initial_suspend返回suspend_always意味着协程被调用后不会立即执行而是暂停在开头。调用者必须显式调用task.resume()来启动它。这给了调用者调度控制权。异常安全通过promise_type::unhandled_exception捕获异常并存储在exception_ptr中提供了在协程外部检查异常的能力rethrow_if_exception。资源管理析构函数负责清理未完成的协程状态帧防止内存泄漏。这是非常重要的一点因为协程状态帧是在堆上分配的。3.3 组合使用编写第一个有意义的协程现在我们可以用Task和SleepAwaitable来写一个简单的协程了。// 一个使用我们自定义Task和SleepAwaitable的协程 Task my_first_coroutine() { std::cout [Coroutine] Step 1, on thread: std::this_thread::get_id() std::endl; co_await SleepAwaitable{std::chrono::milliseconds(500)}; std::cout [Coroutine] Step 2, after sleep, on thread: std::this_thread::get_id() std::endl; co_await SleepAwaitable{std::chrono::milliseconds(500)}; std::cout [Coroutine] Step 3, finished, on thread: std::this_thread::get_id() std::endl; } int main() { std::cout [Main] Start, thread: std::this_thread::get_id() std::endl; auto task my_first_coroutine(); // 此时协程创建并暂停在initial_suspend点 std::cout [Main] Coroutine created, now resume it.\n; // 第一次恢复协程执行到第一个co_await然后SleepAwaitable会启动新线程并暂停协程。 task.resume(); // 主线程可以继续做其他事情 std::cout [Main] Main thread is free to do other work...\n; std::this_thread::sleep_for(std::chrono::milliseconds(100)); // 等待足够长时间让协程内的两个sleep都完成。 // 注意这是一个粗糙的同步等待。真实场景需要更精细的同步机制如条件变量、future。 std::this_thread::sleep_for(std::chrono::seconds(2)); // 检查任务是否完成并处理可能异常 if (task.is_done()) { task.rethrow_if_exception(); std::cout [Main] Coroutine completed successfully.\n; } std::cout [Main] End.\n; return 0; }运行这个程序你会观察到类似以下的输出线程ID会变化[Main] Start, thread: 140735680792448 [Main] Coroutine created, now resume it. [Coroutine] Step 1, on thread: 140735680792448 [Main] Main thread is free to do other work... [Coroutine] Step 2, after sleep, on thread: 139872494614272 # 注意线程变了 [Coroutine] Step 3, finished, on thread: 139872486221568 # 线程又变了 [Main] Coroutine completed successfully. [Main] End.这个输出清晰地展示了协程的“暂停”与“恢复”协程在main线程开始执行Step 1。遇到co_await SleepAwaitable协程暂停。SleepAwaitable::await_suspend启动了一个新线程去睡眠。main线程立即获得控制权继续打印并做自己的事。500ms后新线程睡眠结束调用handle.resume()。这个恢复操作发生在新线程上所以Step 2在新线程打印。第二个co_await同理可能在另一个新线程恢复。实操心得这里暴露了一个关键问题——线程安全性。我们的SleepAwaitable在哪个线程回调协程就在哪个线程恢复。这可能导致数据竞争如果协程访问了共享数据和性能问题频繁的线程切换。在生产级框架中await_suspend通常不会直接在新线程恢复而是将恢复工作提交到一个特定的执行器Executor或调度器Scheduler比如一个IO线程池由执行器决定在哪个线程上安全地调用handle.resume()。这是手搓框架与成熟库如cppcoro, folly::coro的核心差距之一。4. 进阶实现一个链式调用的Generator除了异步任务协程另一个经典应用场景是生成器。生成器可以惰性地产生一个序列节省内存。我们用co_yield来实现一个简单的Range生成器。4.1 定义Generator类型templatetypename T class Generator { public: struct promise_type; using handle_type std::coroutine_handlepromise_type; struct promise_type { T current_value_; // 存储当前yield的值 Generator get_return_object() { return Generator{handle_type::from_promise(*this)}; } std::suspend_always initial_suspend() noexcept { return {}; } std::suspend_always final_suspend() noexcept { return {}; } void unhandled_exception() { std::terminate(); } // 处理 co_yield value; std::suspend_always yield_value(T value) noexcept { current_value_ std::move(value); return {}; // 总是暂停让调用者来取走值 } void return_void() noexcept {} }; // 迭代器支持让Generator可以用范围for循环 struct iterator { handle_type handle_; bool is_end_; iterator(handle_type handle, bool is_end false) : handle_(handle), is_end_(is_end) {} iterator operator() { if (!handle_.done()) { handle_.resume(); // 恢复协程到下一个co_yield或结束 if (handle_.done()) { is_end_ true; } } else { is_end_ true; } return *this; } bool operator!(const iterator other) const { // 简化比较只比较是否是结束迭代器 return is_end_ ! other.is_end_; } const T operator*() const { return handle_.promise().current_value_; } }; iterator begin() { if (handle_ !handle_.done()) { handle_.resume(); // 启动协程到第一个co_yield } return iterator{handle_, handle_.done()}; } iterator end() { return iterator{handle_, true}; } explicit Generator(handle_type handle) : handle_(handle) {} Generator(Generator other) noexcept : handle_(std::exchange(other.handle_, nullptr)) {} ~Generator() { if (handle_) handle_.destroy(); } private: handle_type handle_; }; // 使用Generator的协程函数 Generatorint range(int start, int end, int step 1) { for (int i start; i end; i step) { co_yield i; // 每次yield一个值并暂停 } // co_return; 可省略因为return_void是默认行为 } int main() { std::cout Range generator: ; for (int num : range(0, 10, 2)) { // 惰性生成0, 2, 4, 6, 8 std::cout num ; } std::cout std::endl; // 手动迭代方式 auto gen range(5, 8); auto it gen.begin(); while (it ! gen.end()) { std::cout *it ; it; } std::cout std::endl; return 0; }这个Generator的实现展示了co_yield的魔力yield_value接收yield的值存储到promise中并返回一个suspend_always让协程暂停。迭代器的operator通过handle_.resume()驱动协程前进到下一个co_yield。范围for循环语法完美适配让生成器的使用直观又高效。注意事项生成器协程的final_suspend也必须返回suspend_always以保证协程在结束后其状态帧和promise仍然有效直到Generator对象析构调用destroy()。如果返回suspend_never编译器可能会在协程结束时自动销毁状态帧导致迭代器访问悬空指针。5. 避坑指南与性能考量在实际项目中使用C20协程你会遇到不少坑。这里记录一些常见的陷阱和对应的解决思路。5.1 生命周期管理悬挂引用与use-after-free这是协程编程中最危险的问题之一。协程的状态帧包含局部变量在堆上其生命周期与普通函数栈帧不同。坑1在协程中捕获局部变量的引用或指针。Task bad_coroutine() { int local_var 42; // 启动一个异步操作并尝试传递local_var的引用 co_await some_async_op_that_captures_by_ref(local_var); // 危险 // 如果协程在此暂停而调用bad_coroutine的函数已经返回local_var的内存就失效了。 }解决方案默认按值捕获或者使用std::shared_ptr/std::unique_ptr来管理跨协程暂停点的数据生命周期。对于类成员变量要确保协程执行期间对象本身this是存活的。坑2协程句柄的非法使用。协程句柄是裸指针复制它不会增加引用计数。如果原始的Task对象被移动或销毁其持有的句柄可能被置空或销毁此时再用其他副本去resume()或destroy()会导致未定义行为。解决方案妥善管理Task对象的生命周期遵循RAII。考虑使用std::shared_ptr包装句柄或者实现引用计数的Promise类型但这会增加复杂度。简单的做法是明确所有权确保只有一个对象负责管理句柄的生命周期。5.2 调度与线程安全我们的简单示例中SleepAwaitable在任意线程恢复协程这非常不安全。解决方案引入执行器Executor一个典型的模式是在await_suspend中不直接恢复协程而是将恢复任务提交到一个全局的或传入的执行器队列。struct ScheduledSleepAwaitable { std::chrono::milliseconds duration; Executor executor; // 引用一个执行器 bool await_ready() const { /* ... */ } void await_suspend(std::coroutine_handle handle) const { // 1. 安排一个定时任务 executor.schedule_after(duration, [handle]() { // 2. 定时结束后将恢复任务提交回执行器确保在正确的线程上下文恢复 executor.post([handle]() { if (!handle.done()) { handle.resume(); } }); }); } void await_resume() const {} };执行器内部维护一个任务队列和一个或多个工作线程。post方法将任务放入队列工作线程从中取出执行。这样无论异步操作在哪个线程完成协程的恢复都被序列化到执行器指定的线程上消除了数据竞争。5.3 调试与可视化协程的调试比普通函数更困难因为调用栈在暂停时是断裂的。Visual Studio和某些版本的GDB/LLDB已经开始提供协程调试支持但可能不完善。技巧在Promise类型中添加一个唯一的协程ID并在日志中打印。这能帮你跟踪协程的创建、暂停、恢复和销毁全过程。工具考虑使用像clang的-fcoroutine-ts在标准化前或MSVC的协程调试视图来查看状态机。5.4 与现有异步生态的集成你很可能不想从头造轮子而是希望协程能与现有的异步库如Boost.Asio, libuv协同工作。关键在于为这些库的异步操作如asio::async_read实现相应的Awaitable适配器。以Boost.Asio为例templatetypename AsyncStream, typename MutableBuffer asio_awaitablesize_t async_read_awaitable(AsyncStream stream, MutableBuffer buffer) { // 一种实现方式使用asio::use_awaitable这个完成令牌Completion Token // 这需要Asio的“无栈协程”stackless coroutineTS支持或C20协程适配。 // 更通用的模式是手动封装 struct ReadAwaitable { AsyncStream stream; MutableBuffer buffer; std::error_code ec; size_t bytes_transferred 0; bool await_ready() { return false; } void await_suspend(std::coroutine_handle handle) { asio::async_read(stream, buffer, [handle, this](std::error_code err, size_t bytes) mutable { ec err; bytes_transferred bytes; handle.resume(); // 在Asio的io_context线程中恢复 }); } size_t await_resume() { if (ec) { throw std::system_error(ec); } return bytes_transferred; } }; co_return co_await ReadAwaitable{stream, buffer}; }许多现代库如Boost.Asio 1.80 Qt 6.5已经提供了对C20协程的原生支持直接使用它们提供的awaitable类型或适配器是更稳妥的选择。6. 工程实践设计一个简单的协程化TCP Echo服务器让我们把上面的知识整合起来设计一个概念性的、使用协程的TCP Echo服务器。这里我们假设有一个虚构的、支持协程的网络库它提供了co_await友好的Socket和Acceptor。// 假设的协程化网络库接口 namespace net { class Socket { public: Tasksize_t async_read(void* buffer, size_t size); Tasksize_t async_write(const void* buffer, size_t size); void close(); }; class Acceptor { public: TaskSocket async_accept(); }; } // 处理单个客户端连接的协程 Task handle_client(net::Socket client_socket) { char buffer[1024]; try { while (true) { // 异步读取数据协程在此暂停直到有数据可读或连接关闭 auto bytes_read co_await client_socket.async_read(buffer, sizeof(buffer)); if (bytes_read 0) { // EOF break; } // 异步回写数据协程再次暂停直到数据全部发送 co_await client_socket.async_write(buffer, bytes_read); } } catch (const std::exception e) { std::cerr Client handling error: e.what() std::endl; } client_socket.close(); std::cout Client disconnected.\n; } // 主服务器循环协程 Task server_loop(net::Acceptor acceptor) { std::cout Echo server started.\n; try { while (true) { // 异步接受新连接协程在此暂停直到有新连接到来 net::Socket client_socket co_await acceptor.async_accept(); std::cout New client accepted.\n; // 为每个新连接“点火”一个处理协程。注意这里需要一种机制来管理这些后台任务的寿命。 // 一种简单方式使用一个全局的、支持协程的任务池来spawn这个任务。 spawn_detached(handle_client(std::move(client_socket))); } } catch (const std::exception e) { std::cerr Server fatal error: e.what() std::endl; } } int main() { net::Acceptor acceptor(/* ... */); auto server_task server_loop(acceptor); // 我们需要一个“事件循环”或“调度器”来驱动这些协程。 // 这个循环会调用类似 io_context.run() 的函数执行等待中的异步操作的回调从而恢复协程。 run_event_loop(); return 0; }这个设计清晰地展示了协程如何将异步IO的复杂性隐藏在线性代码之后。server_loop和handle_client的代码读起来就像是同步的但实际上它们是高度并发的。spawn_detached是一个关键函数它需要将新创建的Task来自handle_client提交给调度器并确保其生命周期持续到协程完成同时避免阻塞主循环。实操心得在生产环境中你需要谨慎管理成千上万个协程任务的生命周期。一个常见的模式是让Task的析构函数不自动destroy句柄而是由调度器统一管理。调度器持有所有活跃协程句柄的引用例如在await_suspend中将句柄存入调度器队列并在协程最终完成final_suspend返回suspend_always后由调度器负责清理。这避免了在协程还在被调度器引用时意外销毁的问题。C20协程是一把强大的利器它改变了我们编写异步代码的范式。虽然标准库只提供了底层工具导致入门门槛较高但一旦理解了Promise、Awaitable、Handle这三驾马车你就能驾驭它或者更好地使用基于它构建的上层库。从手搓一个简单的Task和Generator开始逐步理解线程安全、调度和生命周期管理是掌握这门技术的最佳路径。
