c++中的协程是如何挂起和恢复的_c++ coroutine_handle详解【底层】

C++20协程的挂起与恢复由coroutine_handle显式控制，依赖awaitable对象的await_suspend()行为；resume()跳转至挂起点下一条指令，destroy()显式释放帧内存。

在 C++20 中，协程的挂起与恢复并非由语言直接调度，而是通过用户定义的 coroutine_handle 显式控制——它本质是一个轻量级、可复制的指针包装器，指向协程帧（coroutine frame）的内存首地址。真正决定“何时挂起”“如何恢复”的，是协程函数体内 co_await 表达式所作用的 awaitable 对象的行为，而 coroutine_handle 是执行这些行为的唯一入口。

挂起：由 awaitable 的 await_suspend() 触发

当协程执行到 co_await expr 时，编译器会调用 expr.await_suspend(handle)（若存在）。这个函数的返回值决定了挂起后的行为：

• 返回 void：协程立即挂起，控制权交还给调用者；后续必须手动调用 handle.resume() 才能继续
• 返回 bool：true 表示已自行安排恢复（如投递到线程池），协程挂起且不自动恢复；false 表示未安排，协程立即恢复（即“不挂起”，相当于同步执行）
• 返回另一个 coroutine_handle：协程挂起，并将控制权转移给该 handle（常用于链式协程或尾调用优化）

注意：挂起操作本身不释放协程帧内存，只是将协程状态设为 suspended，并保存当前栈上下文（寄存器、局部变量等）到帧中。

coroutine_handle 的构造与有效性

它不能直接构造，只能通过以下方式获得：

立即学习“C++免费学习笔记（深入）”；

• co_await 表达式中传入的参数（即 await_suspend 的形参）
• promise_type::get_return_object_on_allocation_failure() 等 promise 回调中（需配合自定义分配器）
• 从其他 handle 派生：handle.address() 得到原始指针，再用 from_address() 重建（仅当确定内存有效时）

调用 handle.done() 可判断是否已结束（初始/已恢复完毕/已销毁）；handle.promise() 返回对 promise 对象的引用，用于读写协程状态；handle.address() 返回帧起始地址，可用于内存管理或调试。

达芬奇

达芬奇——你的AI创作大师

166

查看详情

恢复：resume() 的底层含义

handle.resume() 并非“唤醒线程”，而是跳转回协程上次挂起点的下一条指令（由编译器生成的恢复标签决定）。它要求：

• handle 必须有效且指向一个已挂起（!done()）但未被销毁的协程帧
• 协程帧内存必须仍可访问（未被 operator delete 释放）
• 恢复时不会重新进入 promise 构造或初始 suspend，而是从中断处继续执行

若在 resume 前已调用 destroy()，或帧内存被复用，行为是未定义的。因此，典型模式是：在 await_suspend 返回 void 后，由外部事件（IO 完成、定时器触发、另一线程通知）安全地调用 resume()。

销毁协程帧：显式 vs 隐式

协程帧的生命周期独立于 handle：

• handle.destroy()：手动释放帧内存（调用 promise 的析构、operator delete），之后 handle 变为无效
• 隐式销毁：当协程执行到末尾（或抛出未捕获异常），且处于 final_suspend 状态时，编译器会自动调用 destroy() —— 这正是为什么 final_suspend 的 awaitable 通常返回 std::suspend_always（挂起等待显式销毁）或自定义逻辑（如自动回收）

常见错误是 resume 后未及时 destroy，导致内存泄漏；或过早 destroy 后仍尝试 resume，引发崩溃。正确做法是：final_suspend 返回的 awaitable 应明确管理帧生命周期。

基本上就这些。协程没有运行时调度器，没有隐式上下文切换，一切挂起/恢复/销毁都经由 coroutine_handle 和 awaitable 协同完成——它不是语法糖，而是一套可预测、可调试、完全暴露给用户的协作式控制流原语。

以上就是c++++中的协程是如何挂起和恢复的_c++ coroutine_handle详解【底层】的详细内容，更多请关注php中文网其它相关文章！