1. 项目概述为什么C20协程是游戏规则的改变者如果你和我一样在C的深海里扑腾了十几年从模板元编程的奇技淫巧到现代C的智能指针总感觉这门语言在“并发”这件事上始终差那么一口气。我们习惯了用线程、锁、条件变量来构建复杂的并发模型代码写起来像在钢丝上跳舞调试起来更是噩梦连连。直到C20把协程Coroutines正式纳入标准库我才意识到这可能是我职业生涯中遇到的最激动人心的特性之一它带来的范式转变不亚于当年智能指针对资源管理的革新。简单来说C20协程不是库而是一套语言核心机制。它允许你写出看起来像同步顺序执行的代码但实际上却能优雅地挂起和恢复执行实现非阻塞的异步操作。这对于网络服务、游戏引擎、UI响应、文件I/O等大量依赖异步处理的场景来说意味着代码可读性和可维护性的巨大提升。你再也不需要面对层层嵌套的回调地狱Callback Hell或者小心翼翼地在线程间传递数据和同步状态。协程让你用写同步代码的思维去解决异步问题。这不仅仅是语法糖。它背后是一套完整的、编译器支持的无栈协程Stackless Coroutines模型。与有栈协程如许多语言中的goroutine或传统纤程不同无栈协程的状态保存在堆上切换开销极低并且与现有的C对象模型、异常处理、RAII机制完美集成。这意味着你可以安全地在协程中使用局部变量、抛出和捕获异常而不用担心栈溢出或复杂的上下文保存问题。那么谁需要关注C20协程呢我认为有三类人首先是中高级C开发者尤其是从事网络编程、后端服务、游戏开发或高性能计算的工程师协程能直接提升你的生产力和代码质量。其次是架构师和技术决策者理解协程的优劣有助于在新项目中做出更合适的技术选型。最后即便是C新手提前了解这一范式也能让你在未来面对并发问题时多一件趁手的兵器。接下来我们就一层层剥开协程的外壳看看它到底是如何工作的以及怎么把它用起来。2. 协程核心机制与编译器魔法要理解C20协程首先得忘掉“线程”的概念。协程是更轻量级的“执行流”它在线程内部协作式地运行。关键在于三个操作挂起suspend、恢复resume和销毁destroy。编译器会把你写的看起来像函数的协程翻译成一个状态机。2.1 协程的“骨架”承诺类型与协程句柄当你定义一个函数并且函数体内出现了co_await,co_yield,co_return这三个关键字中的任何一个时这个函数就自动成为了一个协程。编译器会为它做大量的代码变换。这个变换的核心围绕两个类型promise_type承诺类型和coroutine_handle协程句柄。promise_type是协程的“控制中心”和“返回中介”。你需要在一个类中定义它通常是协程返回对象的内部类型。编译器会使用它来构造协程的返回对象通过get_return_object()方法。处理初始挂起和最终挂起通过initial_suspend()和final_suspend()方法它们返回一个awaiter等待器决定协程开始和结束时的行为。处理返回值co_return的值会传递给return_value()或return_void()方法。处理未捕获的异常通过unhandled_exception()方法。为co_yield提供支持通过yield_value()方法。coroutine_handle则是一个不透明的指针指向协程帧coroutine frame。协程帧是编译器在堆上分配的一块内存里面保存了协程的局部变量、参数、挂起点状态以及promise_type对象。通过coroutine_handle你可以在外部恢复或销毁一个挂起的协程。// 一个最简单的协程返回类型框架 struct MyTask { // 必须内嵌 promise_type struct promise_type { MyTask get_return_object() { // 通常通过 coroutine_handle::from_promise 来构造返回对象 return MyTask{std::coroutine_handlepromise_type::from_promise(*this)}; } std::suspend_always initial_suspend() noexcept { return {}; } // 启动后立即挂起 std::suspend_always final_suspend() noexcept { return {}; } // 结束后挂起便于清理 void return_void() noexcept {} void unhandled_exception() { std::terminate(); } // 简单处理终止程序 }; std::coroutine_handlepromise_type handle_; explicit MyTask(std::coroutine_handlepromise_type h) : handle_(h) {} ~MyTask() { if (handle_) handle_.destroy(); } // RAII 管理协程帧生命周期 // 恢复协程执行 bool resume() { if (!handle_ || handle_.done()) return false; handle_.resume(); return !handle_.done(); } };2.2 等待器Awaiter与co_await表达式co_await expr是协程的灵魂。expr必须是一个可等待awaitable的对象。一个类型要成为可等待的需要满足一些条件最简单的方式是让它拥有operator co_await()或者定义三个关键成员函数await_ready,await_suspend,await_resume。这样的对象被称为等待器Awaiter。当协程执行到co_await expr时会发生以下步骤await_ready()询问“结果准备好了吗”。如果返回true协程直接继续执行跳过挂起。这用于优化避免不必要的挂起开销。await_suspend(std::coroutine_handle h)如果await_ready()返回false则调用此函数。参数h是当前协程的句柄。在这个函数里你可以做任何事将句柄存入某个任务队列、启动一个异步I/O操作并在完成时恢复协程、或者直接切换到另一个协程。这是实现异步调度的核心。协程挂起await_suspend返回后如果它没有在内部恢复协程当前协程的执行状态被保存到协程帧然后挂起。控制权返回到调用者或恢复者。await_resume()当协程在未来某个时刻被恢复后await_resume()被调用它的返回值就是整个co_await expr表达式的结果。标准库提供了两个最简单的等待器std::suspend_always总是挂起和std::suspend_never从不挂起。它们通常用于promise_type的初始和最终挂起控制。// 一个自定义的简单等待器等待指定次数后恢复 struct CountedAwaiter { int count_; CountedAwaiter(int count) : count_(count) {} bool await_ready() noexcept { std::cout 检查是否就绪当前计数: count_ std::endl; return count_ 0; // 计数小于等于0就绪 } void await_suspend(std::coroutine_handle h) noexcept { std::cout 协程挂起递减计数 std::endl; --count_; // 这里为了演示我们简单地在当前线程恢复它。 // 实际场景中可能会将句柄h提交给调度器在计数满足条件后恢复。 if (count_ 0) { std::cout 计数满足立即恢复协程 std::endl; h.resume(); // 在 await_suspend 中恢复是允许的 } // 否则句柄需要被存储起来由其他逻辑在未来恢复 } int await_resume() noexcept { std::cout 协程恢复返回最终计数: count_ std::endl; return count_; } };2.3co_yield与co_returnco_yield expr可以看作是co_await promise.yield_value(expr)的语法糖。它向调用者返回一个值并挂起协程等待下次被恢复。这对于生成器Generator模式非常有用比如遍历一个序列。co_return expr或co_return用于结束协程的执行。它会调用promise.return_value(expr)或promise.return_void()然后执行promise.final_suspend()返回的等待器操作最后协程进入完成状态handle.done()返回true。注意一个常见的陷阱是final_suspend()的返回类型。如果它返回std::suspend_always协程在结束后会挂起其协程帧和promise对象依然存在需要你手动调用handle.destroy()来释放内存正如上面MyTask析构函数所做。如果返回std::suspend_never协程结束后会自动清理协程帧但你将无法在协程完成后从promise对象中读取最终结果因为对象已销毁。设计时需要根据资源管理策略谨慎选择。3. 从零开始实现一个简易协程任务框架理解了原理我们动手实现一个最简单的协程任务框架SimpleTask。这个框架支持异步启动、等待co_await其他SimpleTask并演示基本的调度。3.1 定义SimpleTask类型我们的目标是让SimpleTask可以co_await另一个SimpleTask实现任务间的依赖。#include coroutine #include exception #include iostream #include utility struct SimpleTask { // 前置声明 promise_type struct promise_type; // 使用 coroutine_handle 来管理协程生命周期 using handle_type std::coroutine_handlepromise_type; struct promise_type { // 存储 co_await 另一个 SimpleTask 时得到的值或异常 std::variantstd::monostate, int, std::exception_ptr result; // 存储当本协程被其他协程等待时那个等待者的句柄用于唤醒它 std::coroutine_handle continuation; SimpleTask get_return_object() noexcept { return SimpleTask{handle_type::from_promise(*this)}; } std::suspend_always initial_suspend() noexcept { return {}; } // 懒加载创建后不立即执行 auto final_suspend() noexcept { // 最终挂起时我们需要检查是否有其他协程在等待我们continuation // 如果有就恢复它。 struct FinalAwaiter { bool await_ready() noexcept { return false; } // 在 final_suspend 的 awaiter 中我们可以安全地访问 promise std::coroutine_handle await_suspend(handle_type h) noexcept { auto promise h.promise(); if (promise.continuation) { return promise.continuation; // 返回要恢复的句柄调度器会恢复它 } return std::noop_coroutine(); // 返回一个空操作句柄表示结束 } void await_resume() noexcept {} }; return FinalAwaiter{}; } void unhandled_exception() noexcept { result std::current_exception(); } void return_value(int value) noexcept { result value; } // 使 SimpleTask 可等待 auto get_return_object_coro() { return get_return_object(); } }; handle_type handle_; explicit SimpleTask(handle_type h) noexcept : handle_(h) {} ~SimpleTask() { if (handle_ !handle_.done()) { handle_.destroy(); // 如果任务未完成就析构需要销毁帧可能危险 } } // 移动构造/赋值管理唯一所有权 SimpleTask(SimpleTask other) noexcept : handle_(std::exchange(other.handle_, nullptr)) {} SimpleTask operator(SimpleTask other) noexcept { if (this ! other) { if (handle_) handle_.destroy(); handle_ std::exchange(other.handle_, nullptr); } return *this; } // 禁止拷贝 SimpleTask(const SimpleTask) delete; SimpleTask operator(const SimpleTask) delete; // 使 SimpleTask 可被 co_await bool await_ready() noexcept { return handle_.done(); // 如果任务已完成无需挂起 } // await_suspend 是关键当协程A await 协程B时A挂起并将A的句柄存入B的promise以便B完成后恢复A void await_suspend(std::coroutine_handle awaiting_coro) noexcept { // 将等待者即调用 co_await 的那个协程的句柄存储到被等待任务的 promise 中 handle_.promise().continuation awaiting_coro; // 然后启动被等待的任务如果它还没开始 if (!handle_.done()) { handle_.resume(); } // 注意这里不返回任何句柄意味着当前协程awaiting_coro保持挂起。 // 它将在被等待任务handle_的 final_suspend 中被恢复。 } // 当被等待的任务完成后此协程恢复并获取结果 int await_resume() { auto result handle_.promise().result; if (result.index() 2) { // 存储的是异常 std::rethrow_exception(std::get2(result)); } return std::get1(result); // 返回整数值 } };3.2 使用SimpleTask编写协程现在我们可以用SimpleTask来写协程了。SimpleTask compute_answer() { std::cout 开始计算答案... std::endl; // 模拟一些异步工作比如 co_await 一个延迟 // 这里我们直接返回一个值 co_return 42; } SimpleTask nested_task() { std::cout 进入嵌套任务 std::endl; int value co_await compute_answer(); // 等待另一个协程 std::cout 获得答案: value std::endl; co_return value 1; } SimpleTask main_task() { std::cout 主任务开始 std::endl; int result co_await nested_task(); // 等待嵌套任务 std::cout 最终结果: result std::endl; co_return result; } int main() { auto task main_task(); // 此时协程被创建但因 initial_suspend 而挂起并未执行 std::cout 协程已创建准备启动... std::endl; // 手动恢复最外层的协程 // 由于我们的 await_suspend 逻辑这会触发一连串的恢复和等待 task.handle_.resume(); // 当 main_task 最终完成其 final_suspend 会返回 noop_coroutine调用链结束。 // 我们需要检查任务是否完成并清理。 if (task.handle_.done()) { std::cout 所有任务执行完毕。 std::endl; } // task 析构时会销毁协程帧 return 0; }运行这段代码你会看到协程如何一步步展开执行。main_task等待nested_tasknested_task又等待compute_answer。compute_answer完成后恢复nested_tasknested_task完成后恢复main_task。这就是协程链式调度的雏形。实操心得在实现await_suspend时是选择返回void、bool还是另一个coroutine_handle需要仔细设计。返回void意味着当前协程挂起等待被其他机制恢复。返回false效果类似void。返回true表示不挂起当前协程立即继续执行很少用。返回另一个协程句柄则会让调度器立即恢复那个句柄所代表的协程这可以实现更复杂的协程调度比如“偷取”工作。4. 协程在真实场景下的应用模式与避坑指南理论和小玩具都玩过了是时候看看协程在真实项目里怎么用了。这里我结合网络编程和游戏开发的两个常见场景分享一下实践模式和踩过的坑。4.1 模式一异步网络请求封装这是协程最典型的应用场景。我们可以用协程封装一个异步的HTTP GET请求。#include boost/asio.hpp #include iostream #include string namespace asio boost::asio; using tcp asio::ip::tcp; // 一个基于ASIO的异步操作等待器 templatetypename AsyncStream, typename MutableBuffer struct async_read_some_awaiter { AsyncStream stream; MutableBuffer buffer; std::error_code ec; std::size_t bytes_transferred{0}; async_read_some_awaiter(AsyncStream s, MutableBuffer b) : stream(s), buffer(b) {} bool await_ready() { return false; } // 总是假设未就绪需要异步等待 void await_suspend(std::coroutine_handle h) { // 发起异步读操作完成时恢复协程句柄 h stream.async_read_some(buffer, [h, this](const std::error_code error, std::size_t bytes) mutable { this-ec error; this-bytes_transferred bytes; h.resume(); // I/O完成恢复协程 }); } std::size_t await_resume() { if (ec) { throw std::system_error(ec); } return bytes_transferred; } }; // 简化版协程任务用于网络操作 struct NetTask { struct promise_type { /* 类似之前的 SimpleTask但更简化处理错误 */ }; std::coroutine_handlepromise_type handle_; // ... 移动构造、析构等 }; NetTask fetch_http_body(asio::io_context io, const std::string host, const std::string port) { tcp::resolver resolver(io); tcp::socket socket(io); // 解析域名 - 这里为了简化假设是同步的。实际应用应用异步解析。 auto endpoints resolver.resolve(host, port); asio::connect(socket, endpoints); // 发送HTTP GET请求 std::string request GET / HTTP/1.1\r\nHost: host \r\nConnection: close\r\n\r\n; co_await async_write_all_awaiter(socket, asio::buffer(request)); // 需要实现类似的 async_write_all_awaiter // 读取响应 asio::streambuf response; std::string body; while (true) { std::size_t n co_await async_read_some_awaiter(socket, response.prepare(1024)); response.commit(n); if (n 0) break; // 连接关闭 // 可以在这里解析头部提取body... } // 将streambuf转为string std::istream is(response); std::string line; while (std::getline(is, line)) { body line \n; } co_return body; }使用起来非常直观asio::io_context io; auto task fetch_http_body(io, www.example.com, 80); // 需要将 task.handle_ 与 io_context 的调度关联这里简化了 io.run(); // 运行事件循环代码完全是顺序逻辑但底层全是非阻塞I/O。可读性远超基于回调的版本。4.2 模式二游戏引擎中的帧间延迟与动画在游戏主循环中经常需要实现“等待N帧”或“在2秒内淡出”这样的效果。用协程可以写得非常优雅。struct FrameDelayAwaiter { int frames_to_wait; FrameDelayAwaiter(int frames) : frames_to_wait(frames) {} bool await_ready() noexcept { return frames_to_wait 0; } void await_suspend(std::coroutine_handle h) noexcept { // 假设有一个全局的游戏更新管理器 GameUpdateManager // 将句柄h和剩余帧数存储到管理器的延迟任务列表中 GameUpdateManager::get().register_delayed_coroutine(h, frames_to_wait); } void await_resume() noexcept {} }; struct TimeDelayAwaiter { float seconds_to_wait; TimeDelayAwaiter(float seconds) : seconds_to_wait(seconds) {} bool await_ready() noexcept { return seconds_to_wait 0.0f; } void await_suspend(std::coroutine_handle h) noexcept { // 注册到基于时间的调度器 GameUpdateManager::get().register_timed_coroutine(h, seconds_to_wait); } void await_resume() noexcept {} }; // 在游戏逻辑协程中 GameTask enemy_ai_coroutine(Enemy enemy) { while (enemy.is_alive()) { // 移动到随机点 co_await enemy.move_to_async(random_point()); // 等待60帧约1秒假设60FPS co_await FrameDelayAwaiter(60); // 播放攻击动画动画持续0.5秒 enemy.play_animation(attack); co_await TimeDelayAwaiter(0.5f); // 发射子弹 spawn_bullet(enemy.position(), player.position()); // 等待2秒后进入下一循环 co_await TimeDelayAwaiter(2.0f); } }这样的AI逻辑清晰得像伪代码完全避免了状态机或者回调函数带来的碎片化。4.3 避坑指南与性能考量协程帧的内存分配默认情况下协程帧通过operator new在堆上分配。对于高性能场景这可能是瓶颈。解决方案在promise_type中重载operator new和operator delete使用内存池或栈分配器进行优化。一些第三方库如folly::coro提供了自定义分配器的支持。异常安全协程中未捕获的异常会调用promise.unhandled_exception()。你必须在这里处理异常否则协程帧可能无法正确销毁导致资源泄漏。最佳实践在unhandled_exception中将异常指针存储到promise中然后在await_resume或任务查询结果时重新抛出。确保你的任务析构函数能正确处理含异常的状态。生命周期管理协程句柄coroutine_handle是一个原始指针。你需要用RAII对象如我们的SimpleTask来包装它确保协程帧在合适的时候被销毁。特别注意永远不要在协程挂起时让指向其局部变量或参数的引用/指针逃逸到协程帧外部因为一旦协程恢复并执行完毕这些栈变量就不复存在了。调试困难协程的挂起和恢复破坏了传统的函数调用栈调试器可能无法直观显示完整的逻辑调用链。建议为你的协程任务类型添加有意义的名称或ID在日志中记录协程的创建、挂起、恢复和销毁事件方便追踪。与现有线程池集成协程本身不解决并行问题它解决的是异步并发。你仍然需要线程池来执行CPU密集型工作。常见的模式是I/O操作在事件循环线程中通过协程挂起/恢复而计算密集型任务则co_await一个封装了线程池提交操作的等待器将工作抛到线程池完成后恢复原协程。co_await可等待对象的求值顺序co_await expr中的expr会在当前协程挂起之前被求值。如果expr有副作用需要留意这个时机。例如co_await async_op(counter);会先递增counter再挂起协程。5. 高级话题生成器、无栈协程与有栈协程的对比5.1 实现一个标准库风格的生成器GeneratorC23 可能会将std::generator纳入标准但现在我们可以自己实现一个简化版。生成器用于惰性生成序列。templatetypename T struct Generator { struct promise_type { T current_value; std::exception_ptr exception; Generator get_return_object() { return Generator{std::coroutine_handlepromise_type::from_promise(*this)}; } std::suspend_always initial_suspend() noexcept { return {}; } std::suspend_always final_suspend() noexcept { return {}; } void unhandled_exception() { exception std::current_exception(); } // 关键yield_value 挂起并保存值 std::suspend_always yield_value(T value) noexcept { current_value std::move(value); return {}; } void return_void() noexcept {} }; std::coroutine_handlepromise_type handle_; explicit Generator(std::coroutine_handlepromise_type h) : handle_(h) {} ~Generator() { if (handle_) handle_.destroy(); } // 迭代器支持 struct sentinel {}; struct iterator { std::coroutine_handlepromise_type handle_; bool done_; iterator(std::coroutine_handlepromise_type h, bool done) : handle_(h), done_(done) {} T operator*() const { return handle_.promise().current_value; } iterator operator() { if (!done_) { handle_.resume(); done_ handle_.done(); } return *this; } bool operator!(sentinel) const { return !done_; } }; iterator begin() { if (!handle_ || handle_.done()) return iterator{handle_, true}; handle_.resume(); // 执行到第一个 yield bool done handle_.done(); return iterator{handle_, done}; } sentinel end() { return {}; } }; // 使用生成器 Generatorint range(int start, int end, int step 1) { for (int i start; i end; i step) { co_yield i; // 每次 yield 挂起并返回一个值 } } int main() { for (int i : range(1, 10, 2)) { std::cout i ; // 输出: 1 3 5 7 9 } std::cout std::endl; return 0; }5.2 无栈协程 vs. 有栈协程这是协程领域的经典之争C20选择的是无栈协程。特性C20 无栈协程传统有栈协程 (如Boost.Context, Windows纤程)栈内存无独立栈。状态保存在堆上的协程帧中。每个协程有独立的栈消耗内存较大通常MB级别。切换开销极低。只需保存/恢复少量寄存器状态切换在编译器生成的状态机内完成。较高。需要切换完整的栈上下文。与现有代码集成优秀。可无缝使用局部变量、RAII、异常。协程挂起/恢复是显式的co_await。困难。栈切换可能破坏基于栈的假设如栈变量地址。调度灵活性高。挂起点由程序员通过co_await精确控制可与任何事件循环集成。较低。通常由显式的yield()或调度器决定切换点。内存占用较小且可预测。协程帧只包含必要的状态和局部变量。较大。每个协程栈需要预留足够空间以防溢出。适用场景大量成千上万的轻量级并发任务如网络连接、游戏实体行为、异步算法。数量较少、需要完整栈支持、或移植现有使用栈的代码。选择建议对于全新的C项目尤其是高并发服务端或游戏客户端无栈协程是更现代、更高效的选择。它的学习曲线虽然陡峭但带来的代码结构清晰度和性能优势是巨大的。如果你需要与大量使用栈的旧代码交互或者协程数量很少有栈协程可能更简单。5.3 协程与现有异步库的整合你不需要重写整个项目来使用协程。可以逐步采用通过编写适配器等待器来封装现有的基于回调或Future/Promise的异步接口。例如封装一个基于回调的异步接口templatetypename CallbackFn void old_async_api(int param, CallbackFn callback); // 为其创建一个可等待的包装器 struct OldApiAwaiter { int param; std::optionalResult outcome; std::exception_ptr error; bool await_ready() { return false; } void await_suspend(std::coroutine_handle h) { old_async_api(param, [h, this](Result res, std::error_code ec) mutable { if (ec) { this-error std::make_exception_ptr(std::system_error(ec)); } else { this-outcome std::move(res); } h.resume(); // 回调完成时恢复协程 }); } Result await_resume() { if (error) std::rethrow_exception(error); return std::move(*outcome); } };这样你就可以在协程里写Result r co_await OldApiAwaiter{some_param};将老代码平滑地融入新范式。C20协程是一把锋利的瑞士军刀它改变了我们组织异步代码的方式。初学时其复杂性可能会让人望而却步但一旦理解了promise_type、coroutine_handle和awaiter这三驾马车你就会发现它带来的抽象能力是革命性的。从简单的任务链到复杂的生成器从封装异步I/O到管理游戏逻辑协程都能让代码变得更清晰、更易于维护。尽管标准库目前只提供了最底层的工具需要自己搭建框架但社区中已经涌现出像cppcoro、folly::coro这样的优秀库可以作为生产环境的起点。我的建议是先从理解原理和手动实现一个玩具框架开始再逐步应用到项目的非关键路径上积累经验最终你会爱上这种用同步思维写异步代码的畅快感。
1. 项目概述为什么C20协程是游戏规则的改变者如果你和我一样在C的深海里扑腾了十几年从模板元编程的奇技淫巧到现代C的智能指针总感觉这门语言在“并发”这件事上始终差那么一口气。我们习惯了用线程、锁、条件变量来构建复杂的并发模型代码写起来像在钢丝上跳舞调试起来更是噩梦连连。直到C20把协程Coroutines正式纳入标准库我才意识到这可能是我职业生涯中遇到的最激动人心的特性之一它带来的范式转变不亚于当年智能指针对资源管理的革新。简单来说C20协程不是库而是一套语言核心机制。它允许你写出看起来像同步顺序执行的代码但实际上却能优雅地挂起和恢复执行实现非阻塞的异步操作。这对于网络服务、游戏引擎、UI响应、文件I/O等大量依赖异步处理的场景来说意味着代码可读性和可维护性的巨大提升。你再也不需要面对层层嵌套的回调地狱Callback Hell或者小心翼翼地在线程间传递数据和同步状态。协程让你用写同步代码的思维去解决异步问题。这不仅仅是语法糖。它背后是一套完整的、编译器支持的无栈协程Stackless Coroutines模型。与有栈协程如许多语言中的goroutine或传统纤程不同无栈协程的状态保存在堆上切换开销极低并且与现有的C对象模型、异常处理、RAII机制完美集成。这意味着你可以安全地在协程中使用局部变量、抛出和捕获异常而不用担心栈溢出或复杂的上下文保存问题。那么谁需要关注C20协程呢我认为有三类人首先是中高级C开发者尤其是从事网络编程、后端服务、游戏开发或高性能计算的工程师协程能直接提升你的生产力和代码质量。其次是架构师和技术决策者理解协程的优劣有助于在新项目中做出更合适的技术选型。最后即便是C新手提前了解这一范式也能让你在未来面对并发问题时多一件趁手的兵器。接下来我们就一层层剥开协程的外壳看看它到底是如何工作的以及怎么把它用起来。2. 协程核心机制与编译器魔法要理解C20协程首先得忘掉“线程”的概念。协程是更轻量级的“执行流”它在线程内部协作式地运行。关键在于三个操作挂起suspend、恢复resume和销毁destroy。编译器会把你写的看起来像函数的协程翻译成一个状态机。2.1 协程的“骨架”承诺类型与协程句柄当你定义一个函数并且函数体内出现了co_await,co_yield,co_return这三个关键字中的任何一个时这个函数就自动成为了一个协程。编译器会为它做大量的代码变换。这个变换的核心围绕两个类型promise_type承诺类型和coroutine_handle协程句柄。promise_type是协程的“控制中心”和“返回中介”。你需要在一个类中定义它通常是协程返回对象的内部类型。编译器会使用它来构造协程的返回对象通过get_return_object()方法。处理初始挂起和最终挂起通过initial_suspend()和final_suspend()方法它们返回一个awaiter等待器决定协程开始和结束时的行为。处理返回值co_return的值会传递给return_value()或return_void()方法。处理未捕获的异常通过unhandled_exception()方法。为co_yield提供支持通过yield_value()方法。coroutine_handle则是一个不透明的指针指向协程帧coroutine frame。协程帧是编译器在堆上分配的一块内存里面保存了协程的局部变量、参数、挂起点状态以及promise_type对象。通过coroutine_handle你可以在外部恢复或销毁一个挂起的协程。// 一个最简单的协程返回类型框架 struct MyTask { // 必须内嵌 promise_type struct promise_type { MyTask get_return_object() { // 通常通过 coroutine_handle::from_promise 来构造返回对象 return MyTask{std::coroutine_handlepromise_type::from_promise(*this)}; } std::suspend_always initial_suspend() noexcept { return {}; } // 启动后立即挂起 std::suspend_always final_suspend() noexcept { return {}; } // 结束后挂起便于清理 void return_void() noexcept {} void unhandled_exception() { std::terminate(); } // 简单处理终止程序 }; std::coroutine_handlepromise_type handle_; explicit MyTask(std::coroutine_handlepromise_type h) : handle_(h) {} ~MyTask() { if (handle_) handle_.destroy(); } // RAII 管理协程帧生命周期 // 恢复协程执行 bool resume() { if (!handle_ || handle_.done()) return false; handle_.resume(); return !handle_.done(); } };2.2 等待器Awaiter与co_await表达式co_await expr是协程的灵魂。expr必须是一个可等待awaitable的对象。一个类型要成为可等待的需要满足一些条件最简单的方式是让它拥有operator co_await()或者定义三个关键成员函数await_ready,await_suspend,await_resume。这样的对象被称为等待器Awaiter。当协程执行到co_await expr时会发生以下步骤await_ready()询问“结果准备好了吗”。如果返回true协程直接继续执行跳过挂起。这用于优化避免不必要的挂起开销。await_suspend(std::coroutine_handle h)如果await_ready()返回false则调用此函数。参数h是当前协程的句柄。在这个函数里你可以做任何事将句柄存入某个任务队列、启动一个异步I/O操作并在完成时恢复协程、或者直接切换到另一个协程。这是实现异步调度的核心。协程挂起await_suspend返回后如果它没有在内部恢复协程当前协程的执行状态被保存到协程帧然后挂起。控制权返回到调用者或恢复者。await_resume()当协程在未来某个时刻被恢复后await_resume()被调用它的返回值就是整个co_await expr表达式的结果。标准库提供了两个最简单的等待器std::suspend_always总是挂起和std::suspend_never从不挂起。它们通常用于promise_type的初始和最终挂起控制。// 一个自定义的简单等待器等待指定次数后恢复 struct CountedAwaiter { int count_; CountedAwaiter(int count) : count_(count) {} bool await_ready() noexcept { std::cout 检查是否就绪当前计数: count_ std::endl; return count_ 0; // 计数小于等于0就绪 } void await_suspend(std::coroutine_handle h) noexcept { std::cout 协程挂起递减计数 std::endl; --count_; // 这里为了演示我们简单地在当前线程恢复它。 // 实际场景中可能会将句柄h提交给调度器在计数满足条件后恢复。 if (count_ 0) { std::cout 计数满足立即恢复协程 std::endl; h.resume(); // 在 await_suspend 中恢复是允许的 } // 否则句柄需要被存储起来由其他逻辑在未来恢复 } int await_resume() noexcept { std::cout 协程恢复返回最终计数: count_ std::endl; return count_; } };2.3co_yield与co_returnco_yield expr可以看作是co_await promise.yield_value(expr)的语法糖。它向调用者返回一个值并挂起协程等待下次被恢复。这对于生成器Generator模式非常有用比如遍历一个序列。co_return expr或co_return用于结束协程的执行。它会调用promise.return_value(expr)或promise.return_void()然后执行promise.final_suspend()返回的等待器操作最后协程进入完成状态handle.done()返回true。注意一个常见的陷阱是final_suspend()的返回类型。如果它返回std::suspend_always协程在结束后会挂起其协程帧和promise对象依然存在需要你手动调用handle.destroy()来释放内存正如上面MyTask析构函数所做。如果返回std::suspend_never协程结束后会自动清理协程帧但你将无法在协程完成后从promise对象中读取最终结果因为对象已销毁。设计时需要根据资源管理策略谨慎选择。3. 从零开始实现一个简易协程任务框架理解了原理我们动手实现一个最简单的协程任务框架SimpleTask。这个框架支持异步启动、等待co_await其他SimpleTask并演示基本的调度。3.1 定义SimpleTask类型我们的目标是让SimpleTask可以co_await另一个SimpleTask实现任务间的依赖。#include coroutine #include exception #include iostream #include utility struct SimpleTask { // 前置声明 promise_type struct promise_type; // 使用 coroutine_handle 来管理协程生命周期 using handle_type std::coroutine_handlepromise_type; struct promise_type { // 存储 co_await 另一个 SimpleTask 时得到的值或异常 std::variantstd::monostate, int, std::exception_ptr result; // 存储当本协程被其他协程等待时那个等待者的句柄用于唤醒它 std::coroutine_handle continuation; SimpleTask get_return_object() noexcept { return SimpleTask{handle_type::from_promise(*this)}; } std::suspend_always initial_suspend() noexcept { return {}; } // 懒加载创建后不立即执行 auto final_suspend() noexcept { // 最终挂起时我们需要检查是否有其他协程在等待我们continuation // 如果有就恢复它。 struct FinalAwaiter { bool await_ready() noexcept { return false; } // 在 final_suspend 的 awaiter 中我们可以安全地访问 promise std::coroutine_handle await_suspend(handle_type h) noexcept { auto promise h.promise(); if (promise.continuation) { return promise.continuation; // 返回要恢复的句柄调度器会恢复它 } return std::noop_coroutine(); // 返回一个空操作句柄表示结束 } void await_resume() noexcept {} }; return FinalAwaiter{}; } void unhandled_exception() noexcept { result std::current_exception(); } void return_value(int value) noexcept { result value; } // 使 SimpleTask 可等待 auto get_return_object_coro() { return get_return_object(); } }; handle_type handle_; explicit SimpleTask(handle_type h) noexcept : handle_(h) {} ~SimpleTask() { if (handle_ !handle_.done()) { handle_.destroy(); // 如果任务未完成就析构需要销毁帧可能危险 } } // 移动构造/赋值管理唯一所有权 SimpleTask(SimpleTask other) noexcept : handle_(std::exchange(other.handle_, nullptr)) {} SimpleTask operator(SimpleTask other) noexcept { if (this ! other) { if (handle_) handle_.destroy(); handle_ std::exchange(other.handle_, nullptr); } return *this; } // 禁止拷贝 SimpleTask(const SimpleTask) delete; SimpleTask operator(const SimpleTask) delete; // 使 SimpleTask 可被 co_await bool await_ready() noexcept { return handle_.done(); // 如果任务已完成无需挂起 } // await_suspend 是关键当协程A await 协程B时A挂起并将A的句柄存入B的promise以便B完成后恢复A void await_suspend(std::coroutine_handle awaiting_coro) noexcept { // 将等待者即调用 co_await 的那个协程的句柄存储到被等待任务的 promise 中 handle_.promise().continuation awaiting_coro; // 然后启动被等待的任务如果它还没开始 if (!handle_.done()) { handle_.resume(); } // 注意这里不返回任何句柄意味着当前协程awaiting_coro保持挂起。 // 它将在被等待任务handle_的 final_suspend 中被恢复。 } // 当被等待的任务完成后此协程恢复并获取结果 int await_resume() { auto result handle_.promise().result; if (result.index() 2) { // 存储的是异常 std::rethrow_exception(std::get2(result)); } return std::get1(result); // 返回整数值 } };3.2 使用SimpleTask编写协程现在我们可以用SimpleTask来写协程了。SimpleTask compute_answer() { std::cout 开始计算答案... std::endl; // 模拟一些异步工作比如 co_await 一个延迟 // 这里我们直接返回一个值 co_return 42; } SimpleTask nested_task() { std::cout 进入嵌套任务 std::endl; int value co_await compute_answer(); // 等待另一个协程 std::cout 获得答案: value std::endl; co_return value 1; } SimpleTask main_task() { std::cout 主任务开始 std::endl; int result co_await nested_task(); // 等待嵌套任务 std::cout 最终结果: result std::endl; co_return result; } int main() { auto task main_task(); // 此时协程被创建但因 initial_suspend 而挂起并未执行 std::cout 协程已创建准备启动... std::endl; // 手动恢复最外层的协程 // 由于我们的 await_suspend 逻辑这会触发一连串的恢复和等待 task.handle_.resume(); // 当 main_task 最终完成其 final_suspend 会返回 noop_coroutine调用链结束。 // 我们需要检查任务是否完成并清理。 if (task.handle_.done()) { std::cout 所有任务执行完毕。 std::endl; } // task 析构时会销毁协程帧 return 0; }运行这段代码你会看到协程如何一步步展开执行。main_task等待nested_tasknested_task又等待compute_answer。compute_answer完成后恢复nested_tasknested_task完成后恢复main_task。这就是协程链式调度的雏形。实操心得在实现await_suspend时是选择返回void、bool还是另一个coroutine_handle需要仔细设计。返回void意味着当前协程挂起等待被其他机制恢复。返回false效果类似void。返回true表示不挂起当前协程立即继续执行很少用。返回另一个协程句柄则会让调度器立即恢复那个句柄所代表的协程这可以实现更复杂的协程调度比如“偷取”工作。4. 协程在真实场景下的应用模式与避坑指南理论和小玩具都玩过了是时候看看协程在真实项目里怎么用了。这里我结合网络编程和游戏开发的两个常见场景分享一下实践模式和踩过的坑。4.1 模式一异步网络请求封装这是协程最典型的应用场景。我们可以用协程封装一个异步的HTTP GET请求。#include boost/asio.hpp #include iostream #include string namespace asio boost::asio; using tcp asio::ip::tcp; // 一个基于ASIO的异步操作等待器 templatetypename AsyncStream, typename MutableBuffer struct async_read_some_awaiter { AsyncStream stream; MutableBuffer buffer; std::error_code ec; std::size_t bytes_transferred{0}; async_read_some_awaiter(AsyncStream s, MutableBuffer b) : stream(s), buffer(b) {} bool await_ready() { return false; } // 总是假设未就绪需要异步等待 void await_suspend(std::coroutine_handle h) { // 发起异步读操作完成时恢复协程句柄 h stream.async_read_some(buffer, [h, this](const std::error_code error, std::size_t bytes) mutable { this-ec error; this-bytes_transferred bytes; h.resume(); // I/O完成恢复协程 }); } std::size_t await_resume() { if (ec) { throw std::system_error(ec); } return bytes_transferred; } }; // 简化版协程任务用于网络操作 struct NetTask { struct promise_type { /* 类似之前的 SimpleTask但更简化处理错误 */ }; std::coroutine_handlepromise_type handle_; // ... 移动构造、析构等 }; NetTask fetch_http_body(asio::io_context io, const std::string host, const std::string port) { tcp::resolver resolver(io); tcp::socket socket(io); // 解析域名 - 这里为了简化假设是同步的。实际应用应用异步解析。 auto endpoints resolver.resolve(host, port); asio::connect(socket, endpoints); // 发送HTTP GET请求 std::string request GET / HTTP/1.1\r\nHost: host \r\nConnection: close\r\n\r\n; co_await async_write_all_awaiter(socket, asio::buffer(request)); // 需要实现类似的 async_write_all_awaiter // 读取响应 asio::streambuf response; std::string body; while (true) { std::size_t n co_await async_read_some_awaiter(socket, response.prepare(1024)); response.commit(n); if (n 0) break; // 连接关闭 // 可以在这里解析头部提取body... } // 将streambuf转为string std::istream is(response); std::string line; while (std::getline(is, line)) { body line \n; } co_return body; }使用起来非常直观asio::io_context io; auto task fetch_http_body(io, www.example.com, 80); // 需要将 task.handle_ 与 io_context 的调度关联这里简化了 io.run(); // 运行事件循环代码完全是顺序逻辑但底层全是非阻塞I/O。可读性远超基于回调的版本。4.2 模式二游戏引擎中的帧间延迟与动画在游戏主循环中经常需要实现“等待N帧”或“在2秒内淡出”这样的效果。用协程可以写得非常优雅。struct FrameDelayAwaiter { int frames_to_wait; FrameDelayAwaiter(int frames) : frames_to_wait(frames) {} bool await_ready() noexcept { return frames_to_wait 0; } void await_suspend(std::coroutine_handle h) noexcept { // 假设有一个全局的游戏更新管理器 GameUpdateManager // 将句柄h和剩余帧数存储到管理器的延迟任务列表中 GameUpdateManager::get().register_delayed_coroutine(h, frames_to_wait); } void await_resume() noexcept {} }; struct TimeDelayAwaiter { float seconds_to_wait; TimeDelayAwaiter(float seconds) : seconds_to_wait(seconds) {} bool await_ready() noexcept { return seconds_to_wait 0.0f; } void await_suspend(std::coroutine_handle h) noexcept { // 注册到基于时间的调度器 GameUpdateManager::get().register_timed_coroutine(h, seconds_to_wait); } void await_resume() noexcept {} }; // 在游戏逻辑协程中 GameTask enemy_ai_coroutine(Enemy enemy) { while (enemy.is_alive()) { // 移动到随机点 co_await enemy.move_to_async(random_point()); // 等待60帧约1秒假设60FPS co_await FrameDelayAwaiter(60); // 播放攻击动画动画持续0.5秒 enemy.play_animation(attack); co_await TimeDelayAwaiter(0.5f); // 发射子弹 spawn_bullet(enemy.position(), player.position()); // 等待2秒后进入下一循环 co_await TimeDelayAwaiter(2.0f); } }这样的AI逻辑清晰得像伪代码完全避免了状态机或者回调函数带来的碎片化。4.3 避坑指南与性能考量协程帧的内存分配默认情况下协程帧通过operator new在堆上分配。对于高性能场景这可能是瓶颈。解决方案在promise_type中重载operator new和operator delete使用内存池或栈分配器进行优化。一些第三方库如folly::coro提供了自定义分配器的支持。异常安全协程中未捕获的异常会调用promise.unhandled_exception()。你必须在这里处理异常否则协程帧可能无法正确销毁导致资源泄漏。最佳实践在unhandled_exception中将异常指针存储到promise中然后在await_resume或任务查询结果时重新抛出。确保你的任务析构函数能正确处理含异常的状态。生命周期管理协程句柄coroutine_handle是一个原始指针。你需要用RAII对象如我们的SimpleTask来包装它确保协程帧在合适的时候被销毁。特别注意永远不要在协程挂起时让指向其局部变量或参数的引用/指针逃逸到协程帧外部因为一旦协程恢复并执行完毕这些栈变量就不复存在了。调试困难协程的挂起和恢复破坏了传统的函数调用栈调试器可能无法直观显示完整的逻辑调用链。建议为你的协程任务类型添加有意义的名称或ID在日志中记录协程的创建、挂起、恢复和销毁事件方便追踪。与现有线程池集成协程本身不解决并行问题它解决的是异步并发。你仍然需要线程池来执行CPU密集型工作。常见的模式是I/O操作在事件循环线程中通过协程挂起/恢复而计算密集型任务则co_await一个封装了线程池提交操作的等待器将工作抛到线程池完成后恢复原协程。co_await可等待对象的求值顺序co_await expr中的expr会在当前协程挂起之前被求值。如果expr有副作用需要留意这个时机。例如co_await async_op(counter);会先递增counter再挂起协程。5. 高级话题生成器、无栈协程与有栈协程的对比5.1 实现一个标准库风格的生成器GeneratorC23 可能会将std::generator纳入标准但现在我们可以自己实现一个简化版。生成器用于惰性生成序列。templatetypename T struct Generator { struct promise_type { T current_value; std::exception_ptr exception; Generator get_return_object() { return Generator{std::coroutine_handlepromise_type::from_promise(*this)}; } std::suspend_always initial_suspend() noexcept { return {}; } std::suspend_always final_suspend() noexcept { return {}; } void unhandled_exception() { exception std::current_exception(); } // 关键yield_value 挂起并保存值 std::suspend_always yield_value(T value) noexcept { current_value std::move(value); return {}; } void return_void() noexcept {} }; std::coroutine_handlepromise_type handle_; explicit Generator(std::coroutine_handlepromise_type h) : handle_(h) {} ~Generator() { if (handle_) handle_.destroy(); } // 迭代器支持 struct sentinel {}; struct iterator { std::coroutine_handlepromise_type handle_; bool done_; iterator(std::coroutine_handlepromise_type h, bool done) : handle_(h), done_(done) {} T operator*() const { return handle_.promise().current_value; } iterator operator() { if (!done_) { handle_.resume(); done_ handle_.done(); } return *this; } bool operator!(sentinel) const { return !done_; } }; iterator begin() { if (!handle_ || handle_.done()) return iterator{handle_, true}; handle_.resume(); // 执行到第一个 yield bool done handle_.done(); return iterator{handle_, done}; } sentinel end() { return {}; } }; // 使用生成器 Generatorint range(int start, int end, int step 1) { for (int i start; i end; i step) { co_yield i; // 每次 yield 挂起并返回一个值 } } int main() { for (int i : range(1, 10, 2)) { std::cout i ; // 输出: 1 3 5 7 9 } std::cout std::endl; return 0; }5.2 无栈协程 vs. 有栈协程这是协程领域的经典之争C20选择的是无栈协程。特性C20 无栈协程传统有栈协程 (如Boost.Context, Windows纤程)栈内存无独立栈。状态保存在堆上的协程帧中。每个协程有独立的栈消耗内存较大通常MB级别。切换开销极低。只需保存/恢复少量寄存器状态切换在编译器生成的状态机内完成。较高。需要切换完整的栈上下文。与现有代码集成优秀。可无缝使用局部变量、RAII、异常。协程挂起/恢复是显式的co_await。困难。栈切换可能破坏基于栈的假设如栈变量地址。调度灵活性高。挂起点由程序员通过co_await精确控制可与任何事件循环集成。较低。通常由显式的yield()或调度器决定切换点。内存占用较小且可预测。协程帧只包含必要的状态和局部变量。较大。每个协程栈需要预留足够空间以防溢出。适用场景大量成千上万的轻量级并发任务如网络连接、游戏实体行为、异步算法。数量较少、需要完整栈支持、或移植现有使用栈的代码。选择建议对于全新的C项目尤其是高并发服务端或游戏客户端无栈协程是更现代、更高效的选择。它的学习曲线虽然陡峭但带来的代码结构清晰度和性能优势是巨大的。如果你需要与大量使用栈的旧代码交互或者协程数量很少有栈协程可能更简单。5.3 协程与现有异步库的整合你不需要重写整个项目来使用协程。可以逐步采用通过编写适配器等待器来封装现有的基于回调或Future/Promise的异步接口。例如封装一个基于回调的异步接口templatetypename CallbackFn void old_async_api(int param, CallbackFn callback); // 为其创建一个可等待的包装器 struct OldApiAwaiter { int param; std::optionalResult outcome; std::exception_ptr error; bool await_ready() { return false; } void await_suspend(std::coroutine_handle h) { old_async_api(param, [h, this](Result res, std::error_code ec) mutable { if (ec) { this-error std::make_exception_ptr(std::system_error(ec)); } else { this-outcome std::move(res); } h.resume(); // 回调完成时恢复协程 }); } Result await_resume() { if (error) std::rethrow_exception(error); return std::move(*outcome); } };这样你就可以在协程里写Result r co_await OldApiAwaiter{some_param};将老代码平滑地融入新范式。C20协程是一把锋利的瑞士军刀它改变了我们组织异步代码的方式。初学时其复杂性可能会让人望而却步但一旦理解了promise_type、coroutine_handle和awaiter这三驾马车你就会发现它带来的抽象能力是革命性的。从简单的任务链到复杂的生成器从封装异步I/O到管理游戏逻辑协程都能让代码变得更清晰、更易于维护。尽管标准库目前只提供了最底层的工具需要自己搭建框架但社区中已经涌现出像cppcoro、folly::coro这样的优秀库可以作为生产环境的起点。我的建议是先从理解原理和手动实现一个玩具框架开始再逐步应用到项目的非关键路径上积累经验最终你会爱上这种用同步思维写异步代码的畅快感。
