协程与异步运行时（C++20/Lua/结构化并发/IO 后端）

• 有栈（stackful，如 Boost.Fiber）：独立栈+寄存器切换，任意嵌套函数内可挂起，栈切换成本高
• ABI 差异：无栈的帧布局由编译器决定（ABI 不稳定/不跨编译器），有栈仅依赖调用约定（跨语言/库兼容好）
• 工程影响：无栈的"调用链传染"（await 只能在协程内）、有栈的"任意点挂起"（可挂第三方库调用）与栈内存成本

C++20 coroutine 采用无栈（stackless）模型：编译器把协程函数改写为"状态机+帧对象"（frame：协程参数、局部变量（跨越挂起点存活的）、promise、挂起点位置）——挂起时保存"程序计数+帧"（无需保存调用栈，因为挂起点只能是协程自身函数体中的 co_await/co_yield/co_return 语句）；恢复时从帧中装载继续执行。工程特征：一、状态内存=帧（通常一次堆分配（可定制分配器/帧内嵌）），无独立栈——百万协程的内存成本低（帧小）；二、挂起粒度=协程函数的 await 点——调用链中任何"非协程函数"都不能被挂起（co_await 只能写在协程内：普通函数不能 co_await，被协程调用的普通函数若需挂起必须自身也是协程——"传染性"）；三、帧布局由编译器生成（ABI 内部细节）：帧的内存布局、promise 接口（编译器按函数签名生成）在不同编译器/版本间不稳定（不跨编译器 ABI——与语言运行时（分配器/句柄）配合需小心；标准只定义"抽象语义"（promise/awaiter 协议）不定义帧布局）。有栈协程（Boost.Fiber/libaco/Go goroutine）：每个协程有独立调用栈，挂起=保存寄存器现场+切换栈指针——特征：一、任意深度调用链内可挂起（被调用的库函数运行在协程栈上，其内部阻塞/等待点可以让出——可"挂起第三方阻塞调用"（配合异步化））；二、ABI 只依赖平台调用约定（任何遵守 ABI 的 C/C++ 代码可在协程栈上执行与切换——跨语言、跨编译器兼容性好）；三、代价：每协程栈内存（128KB~1MB）与切换成本（栈切换+缓存失效）。

工程差异总结：一、内存——无栈帧小（K 级）vs 有栈栈大（百 K~M 级）；二、挂起能力——无栈仅"协程内 await 点"（异步库必须全部协程化）vs 有栈"任意点"（可封装阻塞库）；三、ABI/兼容——无栈帧编译器私有（同一工具链内使用）vs 有栈仅平台 ABI；四、性能——无栈切换≈函数调用（编译器优化）vs 有栈切换≈任务切换（寄存器+栈）；五、调试——无栈的"协程调用链"不在调用栈中（调试器需协程帧支持）vs 有栈可直接回溯。选型：C++20 原生（无栈）适合"自包含异步链路"（网络库、协程化的业务代码）；Boost.Fiber（有栈）适合"需要挂起存量阻塞库/跨语言"与"任务粒度大"的场景；Go goroutine 是"有栈+动态栈"的运行时实现。工程注意：无栈的"帧+句柄"生命周期（coroutine_handle 管理：悬垂句柄、对称转移防栈溢出）；有栈的"栈溢出防护"（guard page 或固定栈大小）；混合使用（无栈协程内调用有栈运行时）的场景需明确边界。

以"状态表示（帧 vs 独立栈）"为轴对比两模型的挂起能力（await 点 vs 任意点）、ABI（编译器私有 vs 平台调用约定）与内存/切换成本。

• 栈：boost::fiber 固定栈（可配置大小/分配器，无自动增长）；Go 动态栈（2KB 起、拷贝增长）
• 调度：boost::fiber 在线程内调度（需自行把 fiber 分布到线程/每个线程一个 scheduler）；Go 的 G-M-P 全局调度+窃取
• 工程影响：boost::fiber 适合"协作式任务+可控栈"，Go 适合"大量任务+防饿死+自动栈"

抢占差异：boost::fiber 是"协作式"——fiber 之间的切换只发生在"显式让出点"（fiber::yield、阻塞在 fiber 级同步原语（mutex/condition_variable/channel）上、或 scheduler 的调度点）：一个不主动让出的 fiber（长循环/CPU 密集）会独占其线程，其他 fiber 无法运行（无抢占=无运行时中断注入）——因此用 boost::fiber 必须"任务自觉让出"（类比 Tokio 的约束）；Go goroutine 有"异步抢占"（Go 1.14+：runtime 经 SIGURG 信号在安全点打断长运行的 G）——写"坏"的长循环 G 也不会永久饿死其他 G（调度器与 GC 的公平性由运行时兜底）。栈管理差异：boost::fiber 默认固定栈（默认大小可配置（如 128KB），栈分配器可定制（池化、mmap 共享栈））——栈大小由"最坏深度"决定（深递归需显式加大），无自动增长（栈溢出=越界写（无 guard 时静默破坏/有 guard 时 SIGSEGV））；Go goroutine 动态栈（2KB 起、按需拷贝增长（stack copying：分配新栈+重写指针））——"深度自适应"、免栈溢出配置，但拷贝有运行期成本（深递归高频增长时）。调度差异：boost::fiber 的调度器是"每线程一个"（或自建线程池把 fiber 分配到线程）：fiber 不跨线程自动迁移（线程亲和由使用者管理——可自建 work-stealing 的线程池包装）；Go 的 G-M-P 全局调度：G 可跨 P 窃取迁移、syscall 时 P 让渡（运行时统一管理"任务到线程"的映射）。

工程差异落地：一、可控性——boost::fiber 的"无抢占+固定栈"给开发者完全确定性（适合"任务边界明确、协作式模型自然"的嵌入式/低层库），代价是"自觉纪律"；Go 的"抢占+动态栈"免纪律（防写坏代码拖垮全局），代价是运行时开销与"不完全确定性"（抢占点不可预测）。二、内存——fiber 固定栈（可精确预算：N 任务×栈大小）vs Go 动态栈（按需分配，总量=峰值深度和）。三、跨线程——fiber 需自管线程映射（或多线程 scheduler（boost::fibers 的 numcpu 与 work-stealing 支持有限）），Go 原生多线程+迁移。四、与语言集成——boost::fiber 是 C++ 库（需配合线程、与 C++20 协程互操作需适配器），Go 是语言运行时内建（GC、netpoller、channel 一体化）。选型：需要"协作式确定性与 C++ 生态内嵌"用 boost::fiber；需要"海量任务+防饿死+运行时托管"用 Go。注意 boost::fiber 与 PREEMPT_RT/实时系统的配合（无抢占反而利于确定延迟预算）与"fiber 内阻塞系统调用"的纪律。

以"协作式 vs 异步抢占、固定栈 vs 动态拷贝栈、线程内调度 vs G-M-P 全局"三组对比展开，落到可控性/内存预算/跨线程能力的选型差异。

• libaco：共享栈/独立栈两种（独立栈 1MB、共享栈切换时拷贝到共享区）
• libmill/libgo：固定栈（可配置小栈+动态增长（libgo 有栈增长））
• 工程边界：任务数×栈大小<内存预算；深调用链需加大栈；"小而多"任务用共享栈/小栈

三个有栈协程库（libaco（C）、libmill（C）、libgo（C++））都以"每协程独立栈"为模型，默认栈大小通常在 1MB 级（libaco 的独立栈默认 1MB、libmill 默认 1MB 级（可调）、libgo 默认 128KB~1MB 可配置）。1MB 栈的工程边界：一、内存预算——每协程 1MB 栈：100 万协程 = 1TB 虚拟地址空间（x86-64 虚拟空间 128TB 可容纳但 vma 数量（每协程一个栈映射）受 vm.max_map_count 限制（默认 6 万+）——"协程数×栈 vma"成为上限）；物理内存按"实际使用页"提交（栈按需提交：1MB 虚拟只提交使用的页（几 KB~几百 KB））——但"深递归/大帧"的任务会把提交量推向 1MB；"1MB 栈"边界=任务数×（实际栈深度）必须小于内存；二、栈溢出——固定栈：深递归（如递归解析、深度调用链）超出 1MB 即越界写（未映射区域触发 SIGSEGV 或静默破坏（栈底无 guard 时））——需"栈大小按最坏深度配置"或库的 guard page（libgo 有栈增长机制（检测近满自动换栈/增长）、libmill 无自动增长（固定）、libaco 的共享栈切换规避）；三、切换成本与缓存——大栈的切换（保存/恢复 1MB 级栈帧的寄存器+SP 切换本身便宜（寄存器级）），但"栈深→缓存局部性"：协程频繁切换时各协程栈的活跃部分远小于 1MB（缓存友好），深栈协程切换后缓存冷启动（TLB/缓存 miss）；四、虚拟内存与映射管理——mmap 栈（按需提交）vs malloc 栈（提交全量）：mmap+guard 是常规做法（栈底 guard 页检测溢出）；大量栈的 vma 数限制（vm.max_map_count 调大或共享栈复用）。

共享栈（libaco 的 shared stack）：多个协程共用一个"共享栈区"（如 1MB 共享区）：切换时把当前协程栈"保存（拷贝）到其私有存储"（仅保存"活跃部分"）再切出——收益：虚拟内存与 vma 数大幅下降（N 协程只 1 个栈映射）、内存总量=共享区大小+各协程活跃栈和（通常远小于 N×1MB）；代价：切换时"拷贝活跃栈"（内存拷贝成本）——适合"任务小而多、栈使用浅"（活跃栈小拷贝快）；libgo 的"小栈+增长"（默认 128KB 起、可增长）类似"按需"策略。工程边界结论：一、"1MB×N"的内存/vma 边界决定"用共享栈或小栈"（任务数>万级）；二、递归深度边界（固定栈需按最坏路径配大小，或依赖增长机制）；三、任务"浅栈"特征（活跃栈小）适合共享栈；"深栈/长调用链"任务需独立大栈（共享栈拷贝成本高）；四、观测——协程栈实际使用（活跃栈深）、vma 计数（/proc/self/maps 的栈映射数）、溢出事件（SIGSEGV 地址在 guard 附近）。选型：轻量海量任务（网关、连接处理）→ libgo 小栈/增长 或 libaco 共享栈；深度递归型任务（解析器）→ 独立大栈。

以"每协程 1MB 栈的内存/vma 预算、固定栈溢出、切换缓存"三层讲清边界，再以共享栈（拷贝活跃栈省映射）与增长栈对比给出任务形态匹配。

• co_await：挂起当前协程直到 awaitable 就绪（三阶段协议 await_ready/await_suspend/await_resume）——"等待异步操作完成"
• co_return：以值（或无值）结束协程（调用 promise.return_value/return_void）——协程终止
• 边界：co_await 是"等待外部事件"，co_yield 是"主动产出（每次恢复继续）"，co_return 是"结束"；三者都只能出现在协程函数体内

三个关键字定义协程的三种控制语义，只能出现在协程函数体内（函数含任一关键字即为协程）：一、co_await expr——"挂起等待"：求值 expr 得到 awaitable，编译器调用其 await_ready()：若已就绪（true）直接继续（不挂起）；否则调用 await_suspend(handle)（可返回 void/bool/句柄——决定是否真的挂起、挂起后交给谁（对称转移）），协程状态（帧）保存并控制权转出；被恢复（handle.resume()）后调用 await_resume() 取回结果（或抛异常）——语义：等待"异步操作完成"，挂起期间协程不占线程；典型：等待 I/O、等待超时、等待另一个协程。二、co_yield expr——"产出值并挂起"：把 expr 传给 promise.yield_value()（通常保存到 promise 供调用者读取），然后挂起（等待下次 resume）——语义：生成器/流式（每次恢复从 yield 点继续），等价于 co_await promise.yield_value(expr)；用于"惰性序列"（range/生成器）。三、co_return expr（或 co_return；）——"结束协程"：调用 promise.return_value(expr)（或 return_void()）后协程进入完成状态（帧的清理由最终挂起点 final_suspend 决定）——语义：正常终止（销毁帧、通知等待者（如 task 的 future 就绪））；协程体末尾"隐式 co_return"（promise.return_void()）。

语义边界与易错点：一、co_await 与 co_yield 都"挂起"，但方向不同：co_await 是"等外部"（恢复来自外部（I/O 完成/另一协程 resume）），co_yield 是"给外部"（恢复来自"消费方"的 next()）；二、co_return 与"函数 return"不同：协程的 return 必须写成 co_return（否则编译错——"协程内不能使用普通 return"）；三、co_await 可以"挂起而不产出"（task 模型）、co_yield 可以"产出而不等待外部事件"（generator）、两者可组合（yield 后等待）；四、三个关键字都触发"帧+promise"生命周期：promise 的类型（promise_type 的 get_return_object/initial_suspend/yield_value/return_*）决定协程的类型语义（task/generator/lazy）；五、co_yield 常见于"无栈生成器"（std::generator（C++23）/自定义 generator）；co_await 常见于"异步任务"（task/io 协程）。工程注意：co_yield 的"每次恢复从上次 yield 继续"（状态机位置）、co_return 后的析构顺序（局部变量析构、promise 析构、帧释放）、三者的"挂起/结束"都必须被等待者正确消费（否则协程泄漏（未完成帧）或悬垂）。

以"等外部（co_await）/给外部（co_yield）/结束（co_return）"三分语义，结合三阶段 await 协议与 promise 生命周期讲边界，并给易错点。

• await_suspend(coroutine_handle)：挂起时的钩子——返回 void（无条件挂起）、bool（false=不挂起）、handle（对称转移：把控制权转给另一协程）
• await_resume()：恢复后取结果（返回值给 co_await 表达式）或抛异常
• 协议顺序：ready? → suspend（决定挂起与否/转移）→（恢复后）resume；三阶段由编译器在协程状态机中编排

co_await 的求值协议（编译器把表达式展开为三段）：一、await_ready()——判断"异步操作是否已完成"：返回 true 表示"无需等待"（如结果已在手（缓存/已完成的任务））：协程不挂起，直接跳过挂起阶段继续执行（零成本快路径——避免无谓的挂起/恢复调度）；返回 false 表示"需要挂起等待"。二、await_suspend(handle)——决定"如何挂起"：传入当前协程的 coroutine_handle（帧+promise 的句柄）；返回值决定语义：a) void——无条件挂起：控制权返回调用者/恢复者（协程进入挂起态，等待未来 resume）；b) bool——true=挂起（同 void）、false=不挂起（立即继续——"本想挂起但临时决定不挂"（如注册失败）——此时协程继续执行（不经挂起）；c） 另一个 coroutine_handle（对称转移 symmetric transfer）——把控制权直接转移给指定协程（resume 它）而不回到调用者（避免"resume→挂起→回到调用者再 resume 目标"的栈深嵌套——用于调度器内协程链式切换，防栈溢出）；挂起期间协程把"恢复自身"的职责交给外部（存储 handle、注册回调、交给线程池等）。三、await_resume()——协程被恢复（handle.resume()）后调用：返回值作为 co_await 表达式的值（如任务的结果）；也可以抛异常（如异步操作失败——异常经协程帧传播（promise 的 unhandled_exception 捕获））。三阶段编排：编译器在协程帧的状态机中按"准备→挂起（或继续）→恢复取结果"生成代码：await_ready false 且 await_suspend 决定挂起时，帧保存"恢复点=await_resume 之后"；外部（调度器/完成回调）调用 handle.resume() 从该点继续。

工程要点：一、await_ready 的快路径是性能关键（就绪结果零挂起开销）；二、await_suspend 中"不得访问协程局部变量/帧"（挂起期间可保存 handle 供恢复——规范：await_suspend 运行在"协程挂起中"上下文，可安全保存 handle、不可恢复协程本身（若恢复则 UB（需要对称转移/队列延迟恢复））——"在 await_suspend 中直接 resume 同一协程"是常见 bug；三、对称转移（返回 handle）让"await 链"不增长调用栈（协程 A await B，B 完成时把控制转给 A 而非回到 A 的 resume 调用者）；四、三阶段与 promise 的关系（initial_suspend/final_suspend 也用同一协议）；五、测试/调试：用"挂起计数"与恢复栈验证协议顺序（std::coroutine_traits 的定制 awaiter）。结论：三阶段=就绪快路径、挂起决策（含对称转移）、恢复取值的完整挂起协议）。

以"ready（快路径）→ suspend（挂起决策：void/bool/handle 对称转移）→ resume（取结果/抛异常）"讲清三阶段协议与编译器编排，附 await_suspend 内直接 resume 的坑。

• destroy 的责任：持有 handle 的一方（等待者/任务类型）负责"完成后的帧释放"——通过 handle.destroy()；未正确销毁=泄漏（帧未释放）
• final_suspend：协程结束（co_return 后）的最后挂起点——返回 suspend_always 则"协程停在结束点"（等待者需显式 destroy）；suspend_never 则"结束即销毁帧"（自动释放（栈上/无等待者场景））
• 典型设计：task 类型在 co_await 完成/异常处理后 destroy；generator 由迭代器销毁

C++20 协程的帧生命周期分三阶段：一、创建——调用协程函数时分配帧（frame：promise 对象+参数拷贝+局部变量+状态机），返回"协程对象"（promise.get_return_object() 构造，通常持有 coroutine_handle）；二、执行/挂起——协程在 await 点挂起（帧保留），恢复继续；三、结束——协程执行完 co_return（或抛异常被 promise 捕获）后进入"最终挂起点（final_suspend）"，随后帧应被释放。帧释放（destroy）的责任方：协程对象（task/generator）的持有者——因为协程"自己"无法在结束后释放自己（它已结束，控制权已交出）：a) 等待者（co_await task 的调用方）：任务完成（await_resume 返回）后调用 handle.destroy()（释放帧）；b) 若 final_suspend 返回 suspend_never——协程结束时不挂起、帧自动释放（编译器在结束路径直接销毁帧（无需外部 destroy）——适合"无需等待结束/同步完成"的协程（如无返回值的 fire-and-forget：suspend_never 的 final 使"协程结束=帧立即销毁"，但"外部仍持有 handle"会悬垂——需语义上"结束后无人再用 handle"）；c） 若 final_suspend 返回 suspend_always——协程停在"结束点"（帧保留），等待者观察到"协程完成"（如 task 的 future 就绪）后显式调用 handle.destroy()（或经 RAII 包装（task 析构））。

final_suspend 的作用：一、提供"协程完成后的挂钩点"（完成通知：在 final_suspend 的 await_suspend 中唤醒等待者（如把结果交给 future、resume 等待协程（对称转移））——"完成信号"的传递时机）；二、决定"帧由谁销毁"（suspend_never=自动、suspend_always=等待者 destroy）——"销毁责任"的协议；三、让"协程停在完成状态"（调试/检查完成状态）；异常路径：协程抛异常（未被 await_resume/协程体捕获）→ promise.unhandled_exception() 保存异常，协程同样进入 final_suspend（异常在等待者处重新抛出（await_resume 或任务对象））。工程要点：一、泄漏与悬垂——等待者忘记 destroy（帧泄漏（每协程一帧，长时间运行积累））；等待者先销毁再 resume（UB）；"协程自毁"不可行（handle.destroy 只能在"非协程执行中"调用——destroy 自己的协程是 UB（需经对称转移/队列））；二、RAII 封装——task 类型的析构函数 destroy 未完成帧（"取消未启动的协程"）、await 完成路径 destroy；generator 的迭代器/范围析构负责帧；三、调度器场景——task 完成由完成回调"恢复等待者"（final_suspend 中对称转移），等待者随后 destroy（标准 asio/task 库的模式）；四、内存观测——帧分配计数（定制 new/分配器）验证无泄漏。结论：帧生命周期=创建（返回对象）→ 执行/挂起 → final_suspend（完成挂钩+销毁协议）→ destroy（等待者/自动）；"谁 destroy"由 final_suspend 的语义（suspend_never 自动 vs suspend_always 显式）确定。

以"创建-执行-结束"生命周期开题，讲 final_suspend 的"完成挂钩+销毁决策"双重作用，再明确 destroy 责任（等待者 RAII/自动）与泄漏/悬垂坑。

• growing stack：小栈起步（如 2KB~64KB）、按需扩容（拷贝/分段增长）——按"实际使用"占用：内存效率高（大量浅栈任务）
• 代价：增长机制（拷贝（stack copying：重定位指针）或分段（split stack：段间跳转））的运行时开销、增长峰值（频繁扩容抖动）
• 工程：任务深度分布（浅多深少→growing 优；深度稳定且已知→fixed 精确预算）

固定栈（fixed stack，libaco/libmill/Boost.Fiber 默认）：协程创建时分配"配置大小"的栈（如 128KB/1MB，mmap 或 malloc）——内存效率特征：一、分配量=固定大小（与实际使用无关）：任务栈浅（如只用到几 KB）时"分配浪费"（内存预算按 N×大小，实际使用远低——但固定栈的"浪费"是虚拟内存级（mmap 按需提交时物理只提交使用的页——实际物理浪费小；malloc 栈则全量提交））；二、确定性——最坏深度 < 栈大小即可（无需运行时增长机制，切换/访问零额外开销、无"扩容抖动"）；三、溢出风险——深度超配即越界（需 guard 或手动加大）。动态扩展栈（growing stack，Go goroutine、部分 C++ 库（libgo 的增长模式、分段栈））：小栈起步（Go 2KB），栈满（guard 触发）时扩容：一、拷贝式（stack copying，Go）：分配新栈（倍增）、拷贝旧栈内容、重写栈内指针（依赖 GC 位图/栈映射）——内存按"实际峰值深度"占用（大量浅栈任务的内存总量=各任务峰值和，远小于 N×固定大小）；二、分段式（split stack，老 GCC -fsplit-stack、早期 Go）：栈满时在堆上分配新段（"分段跳转"——部分帧移到新段），无整体拷贝但需"跨段指针"复杂处理（热切换开销、与调试/内联冲突，Go 已弃用）。内存效率对比：一、总量——growing 按"实际使用"（浅任务占小内存），fixed 按"配置大小"（虚拟空间 N×size；物理按提交）；二、峰值——growing 的"峰值"=最大深度（深递归任务会增长到大栈），fixed 的峰值=配置值（可能不够）；三、开销——growing 有"增长事件"（拷贝/分段）的运行时成本与抖动（深递归频繁扩容）、拷贝需"暂停在安全点+指针重写"（与 GC/工具链配合）；fixed 无增长开销（零成本切换/访问）。工程选择：一、任务深度分布——"大量浅任务"（连接处理、请求转发）growing（Go/libgo）的内存效率远高于 fixed（1MB×百万 vs 2KB 起）；"深度已知且较深"（解析器、递归）fixed 更稳（无需增长抖动）或 growing+限制；二、确定性/实时——fixed 的"无增长事件"适合延迟预算严格（无扩容毛刺）；三、虚拟内存与 vma——fixed 的 N×size 虚拟空间与 vma 数（mmap 栈每协程一个映射）在"万级任务"受限，growing 的起始小栈映射同样每协程一个 vma（Go 的栈在堆上？Go 的 goroutine 栈是堆分配的（无需独立 mmap）——vma 数与堆分配无关，这是 Go 动态栈的另一优势）；四、观测——实际栈深（pprof 的 goroutine 栈、库的栈使用统计）、扩容次数（增长事件频率）。结论：内存效率=按"实际使用"分配（growing）vs 按"最坏预算"分配（fixed）；浅任务海量场景 growing 胜（且堆分配免 vma 压力），深/确定场景 fixed 胜（免增长开销）。

以"按实际使用 vs 按配置预算"对比两栈的内存效率，展开 growing 的拷贝/分段机制与增长抖动、fixed 的确定性，落到任务深度分布的选型。

• 栈管理的差异：Rust 无"协程栈"概念（无栈可管）——栈上局部变量"跨 await 存活"的被提升进 future 状态（栈→对象）；不跨 await 的仍在调用栈
• 生命周期：future 的栈等价物（状态对象）在"堆或调用者栈"上（Box::pin/固定（pin）——自引用结构（跨 await 的借用）需 pin 保证地址稳定）
• 工程差异：无栈=无栈溢出/栈增长问题（栈管理消失）、但"状态大小"（future 大小）需管理（大 future 栈上/堆分配）、pin 与自引用是特有复杂度

Rust 的 async/await 是无栈（stackless）实现：编译器把 async fn 改写为"状态机 future"（生成的结构体：保存所有"跨 await 存活"的局部变量+状态标记）——没有独立协程栈。栈管理的差异（对比有栈协程）：一、"栈"去哪了——有栈协程的"调用栈"（深调用链、局部变量）在独立栈上；Rust 无栈模型的"栈上局部变量"分两类：跨 await 存活的变量被编译器"提升"进 future 状态对象（生命周期从"栈帧"变为"future 对象"——本质上"栈变量"变成了"堆/调用者栈上的对象"）；不跨 await 的临时变量仍用普通调用栈（挂起时已死）——因此"协程栈的容量问题"转化为"future 对象的大小问题"（future 的大小=跨 await 变量之和+状态机）。二、栈溢出/增长——有栈协程有"栈大小/增长"问题；Rust 无栈模型没有"协程栈"可溢出（状态对象在堆/调用者栈，大小固定（编译期确定））——"深递归 async"表现为"future 嵌套大小"（async 递归需 Box（间接）避免无限大小（recursive async fn 直接编译错（无限类型），需 Box 或自引用技巧））。三、pin 与自引用——Rust 特有的"栈管理"问题：future 状态可能含"自引用"（跨 await 的变量借用 future 内其他字段（如 &self 的引用/指向自身缓冲的指针））——自引用结构移动地址即失效（悬垂）——因此 future 需"固定（pin）"（Pin<&mut F>）：保证对象地址稳定（不移动）后才可轮询（poll）：堆上的 Box::pin 或栈上"不再移动"的 pin 局部；这是"无栈模型的地址稳定性"管理（有栈协程的栈天然不动，无此问题）。四、内存位置与大小——future 可以完全在栈上（局部变量直接 poll（单层 async fn）——零堆分配）或装箱（动态分发、递归、跨函数传递）；"future 大小"影响栈上使用（大 future 占调用者栈空间——Box::pin 把大状态移到堆，避免栈压力）——"栈管理"变成"状态对象的内存策略（栈/堆）"。工程差异落地：一、无栈=无"协程栈溢出/增长"（简化运行时，任务内存=状态对象大小（通常几十~几百字节，远小于栈））——海量任务内存效率高；二、代价=自引用/pin 复杂度（借用检查器+Pin API 是学习曲线）与"大状态装箱"的手工管理；三、递归 async 需 Box 间接（编译期大小无限问题）；四、与有栈（Go/Boost.Fiber）对比：Go 的动态栈有"栈拷贝+增长"运行时开销但无 pin 概念（GC 移动对象自动更新指针）；Rust 无增长开销但"地址固定"是语言层契约。工程实践：用 Box::pin 处理递归/大状态、pin! 宏栈上固定、监测 future 大小（size_of::()）、把大缓冲移出 future（引用外部 Arc/池）。结论：无栈模型的"栈管理"=状态对象的大小/位置/固定性管理；消除了栈增长与溢出问题，引入了 pin/自引用与装箱策略。

以"栈变量提升为 future 状态对象"讲清无栈模型的栈等价物，再以 pin/自引用（地址稳定性）、递归 Box 间接、栈/堆放置策略展开 Rust 特有的管理。

• Tokio：reactor（mio 封装 epoll/kqueue/io_uring）注册 fd 兴趣（interest）与任务 waker 关联——就绪事件→把任务（future）推入 worker 队列→轮询
• Go：netpoller（runtime 内建 epoll/kqueue 封装）——goroutine 阻塞在网络 I/O 时"挂到"netpoller 的等待队列（保存 goroutine 状态），就绪时由 sysmon/netpoll 唤醒重新入队
• 差异：Tokio 的"注册-唤醒"经 waker（可移植、用户态），Go 的 netpoller 直接操纵 G 状态（运行时内建、零用户态层）

两者的共同骨架："异步 I/O 等待（事件循环）+ 任务就绪唤醒（调度器）"。Tokio：一、reactor——mio（跨平台封装：Linux 的 epoll、macOS 的 kqueue、io_uring（实验））维护"fd→兴趣事件（可读/可写）"注册表；二、任务与 I/O 的关联——异步 I/O 原语（TcpStream::read 等）注册"当前任务的 waker"到 reactor 的 Interest 表（poll 时把 waker 挂到该 fd 的就绪回调上）；三、唤醒路径——fd 就绪（epoll_wait 返回）→ reactor 把"就绪的 interest 对应的 waker"唤醒（wake()）→ waker 把该 future 推入其所属 worker 的本地队列（或标记）→ worker 轮询（poll）该 future 继续执行——"事件→任务"的映射经 waker（每个任务一个，可跨线程唤醒）。四、调度——worker 线程循环"poll 任务队列 + 处理 reactor 事件"（两者在同一个线程循环中整合）。Go：一、netpoller——runtime 内建的 epoll（Linux）/kqueue（macOS）/io_uring（部分）封装：goroutine 执行阻塞网络操作（如 conn.Read）时，runtime 把该 G 与 fd 挂到 netpoller 的等待结构（保存 G 状态到"pollDesc"），G 让出（park）；二、唤醒路径——fd 就绪（epoll_wait 由 sysmon 或"专门等待的 M"执行）→ netpoller 找到对应 pollDesc → 唤醒对应 G（把 G 置为 runnable 放入 P 的本地/全局队列）→ 调度器执行该 G 继续 I/O——"事件→goroutine"的映射由运行时直接管理（pollDesc 持有 G 引用）。三、集成——netpoller 的等待由 sysmon（后台监控线程）或"netpoll 阻塞的 M"驱动（runtime.netpoll 在调度点轮询），与 G-M-P 调度器一体化（无需用户态 waker 层）。

差异：一、唤醒机制——Tokio 用"waker 对象"（用户态可移植（跨平台抽象）、由 reactor 调用 wake() 把任务送进队列——任务与线程的绑定（worker 归属）由 waker 记录）；Go 直接操纵"G 状态机"（G 从 waiting→runnable 由 runtime 完成，无独立 waker 层——更快（无分配？Go 的 pollDesc 预先分配）但绑死运行时）；二、事件循环归属——Tokio 的 reactor 与 worker 在同一进程内用户态协作（一个 runtime 多 worker 共享一个 reactor（或每 worker 反应器（多线程模式）））；Go 的 netpoller 是运行时全局（所有 P 共享，由 sysmon/调度点驱动）；三、io_uring——Go 的实验性集成（GOEXPERIMENT=io_uring 的 netpoll 后端）与 Tokio 的 io_uring 支持都是"把 SQ/CQ 映射为事件源"；四、任务迁移——Tokio 任务经 waker 可被任意 worker 唤醒（配合 work-stealing），Go 的 G 就绪后进入"原 P 或窃取"（调度器决策）。工程启示：一、理解"异步 I/O 不阻塞线程"的机制（reactor+唤醒）是排障基础（"任务卡住"查：fd 是否注册、waker 是否被唤醒（Tokio 的 metrics）、G 是否在 netpoll 等待（pprof 的 IO wait））；二、把"阻塞系统调用"混入事件循环会卡死 reactor（Tokio 的 spawn_blocking、Go 的 syscall 让渡 P）；三、事件循环驱动（epoll 就绪→任务）的延迟=就绪通知延迟+队列延迟（尾延迟排查的着眼点）。

以"reactor 注册-就绪-唤醒"的通用模型为主线，分别还原 Tokio（mio+waker→worker 队列）与 Go（netpoller+pollDesc→G 入队）的挂接细节并对比唤醒机制差异。

• Go 栈模型：起始 2KB（实际 2~8KB）、随深度动态增长（倍增），栈在堆上分配（可移动）
• stack copying：增长时分配新栈、把旧栈帧逐帧拷贝、重写"指向栈内地址的指针"（据栈映射/GC 位图定位指针位置）
• 增长触发：函数序言检查"栈剩余空间"（morestack/栈边界），不足则 runtime 扩容（拷贝）——无硬件依赖（也不需要 mprotect/页错误路径）

Go goroutine 的栈：初始约 2KB（实际按平台与 GOMAXPROCS 为 2~8KB 起），动态增长——每次函数调用前，序言检查"当前栈剩余空间"（编译器插入的栈边界检查（go:stackcheck/morestack 语义）），不足时 runtime 触发栈扩容：一、栈复制（stack copying）流程——分配新栈（大小倍增（如 2KB→4KB→8KB…，上限 maxstacksize 默认 1GB））→ 把旧栈的每一帧拷贝到新栈（按帧的"大小+指针位置信息"逐帧搬移）→ 重写"指向栈内对象/帧的指针"：runtime 依据编译器生成的"栈映射（stack map，GC 位图：每个安全点记录栈上哪些槽位是指针）"定位旧栈中的指针槽位，把指向旧栈地址的指针值改为"新栈中的对应地址"（旧地址→新地址的偏移换算）→ 切换栈指针（SP）到新栈、继续执行——拷贝期间 goroutine 必须暂停在"安全点"（不与 GC 并发扫描冲突——栈复制与 GC 的栈扫描共用栈映射机制）。二、为什么不需要 guard page——guard page 是"固定大小栈"的溢出检测机制（mmap 栈底放不可访问页：栈溢出触碰 guard 触发 SIGSEGV——检测"越界"而非"扩容"）；Go 的栈是"可增长对象"（堆分配、无固定边界）：溢出检测是"软件检查"（函数序言比较 SP 与栈边界（栈顶的边界值/哨兵），不足则走扩容路径（morestack→runtime 增长））——不依赖硬件页错误（无需 guard、无 SIGSEGV 路径）；栈增长是"正常的运行时事件"而非"错误"。代价与细节：一、栈复制需要"指针信息"（栈映射）——这是"精确 GC"的副产品（编译器在安全点输出栈位图）；二、复制期间"指向栈的指针"必须全部可定位（含寄存器中的指针（寄存器栈映射）、汇编帧（无映射则不可复制（Go 保证汇编帧可处理/特殊处理））；三、拷贝成本与抖动——深递归/高频扩容时有拷贝开销（增长按倍增摊销：总量 O(最终大小)）；四、对比——有 guard page 的固定栈（C++ fiber 等）：溢出=崩溃（SIGSEGV）且需配置栈大小；Go 无 guard、无配置（自动），代价是"栈复制与映射"的运行时复杂度。工程要点：一、深递归（如超 1GB 栈）最终触发"goroutine 栈超出限制"panic（不是溢出崩溃，是限制）；二、性能——高频深递归场景的栈拷贝可见（perf 的 runtime.morestack）、大栈帧（巨大局部变量）增长频繁（减少栈上大对象）；三、与 cgo/汇编的边界（无栈映射的帧不能跨拷贝？cgo 调用切换到线程栈执行）。结论：Go 用"软件边界检查+拷贝扩容"替代"硬件 guard+固定大小"——栈成为"可移动对象"，其指针更新依赖精确栈映射（GC 位图），无需 guard page（无硬件溢出概念））。

以"序言边界检查→扩容→逐帧拷贝+栈映射重写指针"讲清增长机制，再以"可增长对象 vs 固定边界"对比 guard page 语义，说明软件检查替代硬件溢出检测。

• coroutine.create(f) 创建（suspended）；coroutine.resume(co,...)：启动/恢复（传参/传值）；coroutine.yield(...)：挂起并回传值（控制回 resume 者）
• 数据传递：resume 的参数→协程函数参数（首次）/yield 的返回值（恢复时）；yield 的参数→resume 的返回值
• 实现：每个协程是独立 Lua 栈+调用栈（lua_State 内嵌），切换=保存/恢复"协程执行上下文"

Lua 5.x 的协程是"非对称（asymmetric）、有栈（stackful）"协程：coroutine.create(f) 创建新协程（独立 lua_State：自己的 Lua 栈、调用栈、指令指针）——初始状态 suspended；coroutine.resume(co, ...) 从"挂起/初始"状态恢复执行（参数传给协程函数（首次）或作为"上次 yield 的返回值"（恢复时））；协程内 coroutine.yield(...) 挂起自己并把参数"返回"给 resume 调用者（resume 返回这些值）；控制流永远是"resume 者↔被 resume 者"的配对（非对称：yield 只能回到 resume 自己的那个调用者，不能直接转移到其他协程（对称转移需自行实现/或用协程调度器包装））。状态机四态：一、suspended——创建后未运行、或运行中被 yield（可被 resume）；二、running——正在执行（只有一个（当前 CPU 上的活动协程）；三、normal——"运行中但被其他协程 resume"（A resume B 时，A 处于 normal：A 被"暂停"但未 yield——B yield 时控制回到 A；normal 状态不可被其他协程 resume（只能由 resume 它的那个协程继续））；四、dead——协程函数正常返回或出错：不再可 resume（resume dead 协程报错）；错误处理：协程内错误经 resume 返回（error 对象）而非传播（protected 调用语义））。

数据传递模型（对称于调用）：一、首次 resume(co, a, b)：a、b 成为协程函数参数；二、协程内 yield(x, y)：resume 调用返回 x、y（及"是否正常结束"标记）；三、恢复 resume(co, c)：yield 表达式的结果为 c（resume 传回的值）；四、协程 return 值：resume 返回之（dead）。实现：每个协程一个 lua_State（Lua 栈+调用栈（CallInfo 数组）），切换=保存当前协程的"执行上下文（栈顶/调用栈/PC）"并恢复目标协程——Lua 的"协程是独立解释器状态"模型（对比 C++ 的帧对象或 Go 的 G）。工程要点：一、非对称语义的"层级"——协程嵌套 resume（A resume B、B resume C）形成调用链（yield 只能逐级返回（B yield 回 A（A 处于 normal）——C yield 回 B））；二、Lua 栈容量——协程的 Lua 栈默认同主状态（lua_State 栈可增长（Lua 5.4 的 LUAI_MAXSTACK 限制））；三、yield 的"C 函数边界"——C 函数中不能跨"非 yield-aware"的 C 调用 yield（Lua 5.x 限制：只能从"主调用链中的 Lua 层" yield——C API 的 lua_yieldk 处理）；四、与"线程"的区别——协程是协作式、单线程内（Lua 的 lua_State 可以是独立线程（多 OS 线程各一个状态）——协程与 OS 线程正交）；五、状态查询——coroutine.status(co) 返回四态之一。结论：Lua 协程状态机=resume/yield 配对的 suspended/running/normal/dead 流转+独立 lua_State 的上下文切换，是非对称有栈模型的经典实现。

以"非对称 resume/yield 配对 + 四态状态机（suspended/running/normal/dead）+ 数据传递双向模型"讲清 Lua 协程，并说明独立 lua_State 的实现与 C 边界 yield 限制。

• 问题：Lua 协程 yield 时，若"被挂起的调用链"包含 C 函数帧，C 函数的"中间状态"（局部变量、执行位置）无法被 Lua 解释器保存（C 栈不在 Lua 管理内）
• lua_yieldk：C 函数在"需要 yield 的 API 调用"处返回"yield 请求"（lua_yieldk 传 continuation 函数），恢复时解释器调用 continuation 继续 C 函数的剩余逻辑
• 工程价值：让"IO 库/协程库"（如 lua-socket、协程化的 C 库）能在 C 实现中挂起而不阻塞——"阻塞 C 调用"在协程里可以"让出"（配合事件循环）

问题本质：Lua 协程的挂起（yield）需要保存"被挂起调用链的全部执行状态"——Lua 层代码的状态（Lua 栈+调用栈）由解释器保存，但"C 函数帧"的执行状态（C 局部变量、C 调用栈中的位置）不在 Lua 解释器的管理范围（无法保存/恢复）——因此默认规则：yield 只能发生在"Lua 代码"的执行中；若调用链经过 C 函数且该 C 函数试图 yield（或调用会 yield 的 API（如 lua_call 一个会 yield 的 Lua 函数）），报错"attempt to yield across a C-call boundary"（Lua 5.1 起此错误在部分 API 上可避免（lua_callk 等））。yield-aware C function 的机制：C 函数在"需要挂起的点"不"继续执行"而是调用 lua_yieldk(L, nresults, ctx, continuation)：它把当前"yield 的值"压栈并返回"特殊值"给解释器——解释器把协程挂起（状态保存到 Lua 侧）；协程恢复（resume）时，解释器调用 continuation 函数（把 ctx 与 resume 传回的值作为参数）——C 函数的"剩余逻辑"在 continuation 中继续（continuation 是"恢复点"：C 函数拆成"yield 前部分+continuation（yield 后部分）"两段——本质是"C 层的手工状态机/闭包续延"）。配套 API：lua_callk/lua_pcallk（允许从被调 Lua 函数 yield（传 continuation））、lua_getctx（continuation 中取 ctx）；IO/协程库（lua-socket 的 timeout 模型、luv（libuv 绑定）、协程化驱动）用此模式。

工程价值：一、"异步 I/O 的协程化"——C 实现的阻塞操作（socket 读写、文件、计时）在协程内"挂起让出"（不阻塞其他协程）：C 库发起非阻塞 I/O 后 lua_yieldk 挂起，事件循环就绪后 resume 协程、经 continuation 继续 C 逻辑——"C 库与 Lua 协程协同"（LuaSocket 的 receive（'*a' 之类在协程模式下的让出）、lua-copas 调度器）；二、"可中断的 C 扩展"——C 扩展的耗时/等待操作可让出（配合超时/取消）；三、"状态机的 C 层实现"——continuation 把 C 函数拆段（显式状态），代价是代码结构（续延式）复杂（对比"阻塞写法"（阻塞在协程内会拖住整个 Lua 状态？单线程 Lua 里阻塞 C 调用拖住一切——yield-aware 让 C 库融入协程调度）。边界与限制：一、只有"显式使用 lua_yieldk 系列"的 C 函数才能跨边界 yield（未标记的 C 调用仍报错——库必须"感知协程"）；二、continuation 的上下文（ctx/结果）需手动管理（无自动保存 C 栈）；三、C 函数在 yield 期间的"资源"（打开的 fd 等）由库自行管理（挂起不自动清理）。结论：yield-aware C function 用"lua_yieldk+continuation"把"C 层挂起"变为显式续延——是"阻塞 C 库协程化"（非阻塞 I/O 接入 Lua 协程调度）的工程基石）。

以"C 帧状态无法由解释器保存"讲清 yield 边界问题的根源，再以 lua_yieldk+continuation 的"拆段续延"机制与异步 I/O 接入场景说明工程价值。

• go 关键字（宏）：创建协程并调度（等价 Go 的 go——"启动异步任务"的声明式语法）
• mill_defer：注册"协程退出时执行"的清理函数（等价 Go 的 defer——保证资源清理（无论正常/异常退出））
• 工程价值：把"协程/异步"用类 Go 语法引入 C（可读性、错误路径清理、结构化并发雏形），但宏实现有约束（作用域、性能）

libmill 是 C 的协程库（有栈、协作式、配合其 channel/等待机制）：一、go 关键字——宏（GO 或 go expr）：把表达式"作为新协程启动"（运行时创建协程并放入调度队列）——语义等价 Go 的 go 语句："启动一个并发任务（协程），当前协程继续"——工程价值：在 C 中表达"异步任务启动"的声明式语法（对比"手工创建线程+函数指针"（libmill 的 go 是协程级（同线程内协作）），让"并发任务"的代码形态接近 Go（可读性、心智模型）；二、mill_defer（defer）——宏：注册"当前协程退出（正常返回/异常）时执行"的清理表达式（栈式 LIFO，等价 Go 的 defer）：工程价值：a） 错误路径的资源清理（"打开→defer 关闭"模式：无论后续 return/错误分支，资源（fd/内存/锁）在协程退出时自动释放）——消除"每个错误分支手写清理"（C 的 goto cleanup 模式的替代）；b) 异常/错误传播下的确定性清理（libmill 协程的错误（如 channel 关闭）经异常式机制传播时 defer 仍执行）。三、配套——channel（mill_channel、mill_choose（select 语义））与 mill_poll/mill_now：构成"协程+通道+选择"的 Go 风格并发原语（CSP 模型）；底层：协程切换（汇编保存/恢复上下文）+ 调度器（每线程一个）。

工程价值总结：一、代码形态——"go + channel + defer"让 C 的并发代码具备 Go 的结构化风格（任务启动、通信、清理三个维度都有声明式原语），降低"异步/并发 C 代码"的出错率（尤其资源清理（defer）与"任务间通信（channel）"）；二、可维护性——清理逻辑集中在 defer 声明处（而非散落各错误分支）；三、适用场景——嵌入式/系统级 C 代码需要"轻量并发+结构化清理"（对比线程：协程轻量、协作式）；局限与边界：一、宏实现——go/defer 是宏（作用域限制（defer 注册在宏展开的作用域）、错误用法（defer 与 return 的交互（Go 中 defer 在 return 后执行——宏需注意）、调试（宏展开后的代码）；二、协作式——阻塞（阻塞系统调用）会拖住全部协程；三、与 C++/RAII 的取舍——C++ 用 RAII（析构）替代 defer 的场景；四、生态——libmill 已停止维护（其作者转向 libdill），新项目评估替代（libaco 等）。结论：libmill 的 go/mill_defer 把 Go 的"任务启动+延迟清理"语法引入 C，工程价值=并发代码的声明式表达与错误路径确定性清理；受宏与维护状态限制））。

以"go（异步任务启动）、mill_defer（退出清理）、channel（通信）"讲清类 Go 语法在 C 中的表达，重点展开 defer 的错误路径清理价值与宏限制。

• symmetric transfer（对称转移）：awaiter 的 await_suspend 返回"另一个协程的 handle"——控制权直接转移给目标协程（不回到中间调用者）
• 工程价值：一、防栈溢出——协程链（A resume B、B resume C…）在非对称模型下调用栈深度=链长；对称转移使"切换"不叠加调用栈（平级跳转）——无限链/深链安全；二、调度器内协程间直接切换（完成→唤醒下一个任务：不经过"返回调度器再 resume"的中间层）——减少调用层与开销
• 实现：await_suspend 返回 handle（编译器生成"tail call 式"转移）；对称转移在"链式 resume"场景是正确性与性能关键

非对称转移（asymmetric transfer，C++20 协程的"常规"模型）：协程挂起时控制权"返回给 resume 它的调用者"——如果 A 协程 resume B、B resume C（链式调度：每个协程"完成/挂起后 resume 下一个"），调用关系是"嵌套"的：A 的 resume 调用 B 的 resume 调用 C 的……——每次"挂起-返回"都回到上一层（yield 语义：B 挂起→控制回到 A（A 继续））——问题：若"链式转移"（B 挂起时直接把控制交给 C（而非回到 A））在非对称模型下需要"A 调 B、B 调 C、C 挂起→回 B→回 A"——调用栈深度=嵌套层数：长链（如 10 万协程的事件循环逐个转移）导致调用栈无限增长（栈溢出）——非对称模型的"每层 resume 占用一层调用栈"。对称转移（symmetric transfer）：awaiter 的 await_suspend 返回"另一个 coroutine_handle"：编译器把"恢复该 handle"编译为"尾调用式转移"（当前协程的帧挂起、控制权"平级"跳到目标协程——不叠加调用栈（类似 goto/尾递归：目标协程的 resume 在"当前调用帧"上执行（复用当前栈帧））——链式转移的调用栈深度保持 O(1)（无论链长））。

调度器场景的工程价值：一、防栈溢出——事件循环/任务调度器的"完成→唤醒下一个"链（协程 A 完成，对称转移到 B、B 完成转移到 C……）：非对称模型在"深链"（每事件一次转移、长任务队列）下爆栈（经典 bug：asymmetric 的"resume 循环"）；对称转移使"无限链式转移"安全（栈深度恒定）——正确性关键；二、效率与简洁——调度器无需"协程挂起→回到调度器代码→再 resume 下一个"的中间层：协程完成（final_suspend/await_suspend）时"直接转移"给下一个任务（一次转移替代"返回+再进入"两次调用）——减少调用层级与间接成本；三、语义清晰——"任务间转移"在代码中显式（返回 handle），调度逻辑（谁唤醒谁）可读。实现细节：一、await_suspend 返回 handle 时编译器生成"对称转移"（标准要求实现不得增加栈深（必须 tail call 等价））；二、返回 void/bool 是"非对称"（控制回 resume 者）；三、final_suspend 返回 handle 也可对称转移（完成时直接交棒）；四、对称转移的"当前协程帧"仍保持挂起（由目标协程最终销毁（等待链的 destroy 责任传递））。工程实践：调度器（asio 的 awaitable 调度、自研任务运行时）用对称转移实现"任务链"（完成即唤醒下一个）；压测深链（10 万级转移）验证栈深度恒定（对比非对称爆栈）；注意"对称转移的帧销毁"链（最后一个协程完成时销毁整链）。结论：对称转移把"协程间切换"从"嵌套调用"变为"平级尾跳"——调度器长链场景防爆栈且少一层间接，是"协程即任务"运行时的关键机制。

以"嵌套 resume 调用栈 vs 尾调用式平级转移"对比两模型，用调度器"完成→唤醒下一个"的链式场景论证防爆栈与省间接的工程价值。

• libunifex：Facebook 的"可组合异步操作"库（sender/receiver 模型，更底层、通用——非"协程类型"而是"异步操作组合"（execution 提案基础））
• asio::experimental::coro：ASIO 的协程支持（基于 ASIO 的异步模型（async_op 的 completion handler 与协程集成））——与 io_context 深度绑定
• 差异：抽象层次（协程类型库 vs sender/receiver 执行模型 vs 网络库集成）、调度器绑定、生态与成熟度

三个库定位不同：一、cppcoro（Lewis Baker 的早期库）——"协程类型与同步原语"库：提供 task（异步任务）、generator/recursive_generator（惰性序列）、async_mutex/async_condition_variable/async_manual_reset_event（异步同步原语）、shared_task、以及"调度器抽象"（配合 ASIO/libuv 的 io_service 使用——本身不含事件循环）：工程特征——把 C++20 协程的"类型语义"（task/generator）标准化、教学价值高（协程概念的经典实现）；生态——维护趋缓（作者转向 sender/receiver 方向（P2300/执行提案））。二、libunifex（Facebook 开源）——"可组合异步操作（sender/receiver）"库：不直接给"协程类型"，而是给出"异步操作的组合模型"：sender（可被调度执行的异步操作）+receiver（结果接收）+操作适配器（then/upon_error/via/let 等组合子）+execution context（线程池/事件循环）：工程特征——更底层、更通用（可表达"流式/取消/调度"的完整执行语义），是 C++ 执行模型（P2300 std::execution）的参考实现；与协程的配合——sender 可 co_await（把 sender 适配为 awaitable），协程可嵌入组合链；适合"库作者/高性能执行框架"。三、asio::experimental::coro——ASIO（网络库）的协程集成：基于 ASIO 的 async_* 操作模型（completion handler 风格）把"异步操作"封装为可 co_await 的 awaitable：工程特征——与 io_context/executor 深度绑定（co_await 的操作挂到 ASIO 的 I/O 服务（epoll 等））、支持 co_spawn（把协程作为任务提交给 io_context 执行）、与 ASIO 生态（定时器、socket、信号）无缝：适合"ASIO 网络程序中的协程化"。

差异总结：一、抽象层次——cppcoro 是"协程类型层"（task/generator+原语）、libunifex 是"执行模型层"（sender/receiver 组合）、asio::experimental::coro 是"网络/事件循环集成层"；二、调度/事件——cppcoro 需外接调度器（自带 basic_io_service 适配）、libunifex 自带执行上下文（inline/thread pool/（可接 io））、asio coro 绑定 io_context；三、能力——libunifex 的"取消/流式/调度组合"最完整（但 API 复杂）、cppcoro 简单直接（教学友好）、asio coro 与 ASIO 生态最融合（网络场景开箱即用）；四、成熟度——asio 最活跃（网络领域事实标准）、cppcoro 半维护、libunifex 活跃但定位库作者。选型：网络服务（ASIO 栈内）用 asio coro；学习协程/通用 task-generator 用 cppcoro（或 C++23 的 std::generator）；构建"执行框架/异步运行时"用 libunifex（或直接 P2300 演进）。工程注意：三者可混用（cppcoro 的 task 配 ASIO 的 executor、libunifex 的 sender 包 asio 操作）但"调度语义"要理清（哪个上下文执行、取消如何传播）；协程库的"帧生命周期"与"调度器亲和"（协程恢复在哪个线程）是集成要点。

以"协程类型层（cppcoro）/执行模型层（libunifex）/网络集成层（asio coro）"三分定位，对比调度绑定、能力与生态，给选型建议。

• 切换（resume/yield）：保存"当前协程的执行状态（栈顶、调用栈、基址指针、PC）"到其 lua_State，恢复目标协程的状态——本质是"解释器状态机的上下文切换"
• 实现细节：Lua 栈（TValue 数组）按需增长（协程栈默认同主状态大小）；调用栈（CallInfo）保存函数帧；切换时"栈顶/栈基/PC"等指针重定位（相对基址）
• 工程：无"汇编级栈切换"（对比 C 协程库）——Lua 协程切换在"解释器层面"（C 栈不变），代价低（解释器状态交换），但"C 函数边界"不可跨

Lua 协程的切换不涉及"汇编级寄存器/机器栈切换"（对比 C 的 stackful 库（ucontext/Boost.Context 的汇编切换））：因为协程的执行是"Lua 解释器解释执行字节码"，解释器的状态（当前协程的执行位置）全部存在于"该协程的 lua_State"中：一、每协程一个 lua_State——包含：Lua 栈（TValue 数组：协程的"操作数栈"）、调用栈（CallInfo 数组：函数调用帧（函数、基址指针、返回地址（指令位置）））、解释器执行状态（PC/指令指针、栈顶指针、当前闭包等）。二、resume/yield 的切换流程（解释器层面）：a) 保存——把当前协程的解释器状态（栈顶指针（L->top）、当前函数帧（L->ci）、PC 等）留在其 lua_State 结构内（不需要"保存到别处"——状态本来就属于该协程）；b) 恢复——把目标协程的 lua_State 设为"当前状态"（lua_State 指针切换）：解释器继续从该协程的 PC/栈顶执行——"切换"= 交换"解释器当前操作的状态"（lua_State 指针 + 恢复其内部指针），本质是"解释器状态机的上下文切换"（C 侧的调用栈（lua_resume 的 C 帧）不因 Lua 协程切换而增长（每次 resume 是一次 C 调用，yield 返回之——非对称语义与 C 调用边界匹配）。三、栈管理细节——Lua 栈增长（协程栈按需扩容（luaD_growstack，受 LUAI_MAXSTACK 限制））；调用栈（CallInfo）数组随深度增长（luaD_growCI）；切换时"栈顶/基址/PC"均为"相对索引/指针"（Lua 栈元素用索引（相对栈基），切换后同一协程恢复时其相对位置一致（栈顶指针（absolute 指针）保存于状态——切换时只需"恢复指针值"）。四、"无 C 栈切换"的工程含义——a） 切换成本低（状态指针交换+少量检查，对比汇编寄存器保存/恢复（C 协程库））；b） 但"C 函数帧"不在 Lua 状态内（C 调用在"解释器的 C 调用栈"上）——yield 跨 C 函数边界即"状态不可保存"（需 yield-aware C function）；c) 协程的"机器栈"是共享的（所有协程运行在同一个 OS 线程的 C 栈上（解释器调用链））——Lua 协程不是"独立机器栈"（无栈溢出/栈增长问题（Lua 栈是管理的数据结构）），也没有"栈拷贝"（对比 Go）；五、性能——Lua 协程切换≈解释器状态交换（百 ns 级），比 C 级栈切换（微秒级）便宜，但每步仍走解释器（非编译代码路径（LuaJIT 的协程处理不同（其编译路径的 yield 特殊处理）））。工程总结：Lua 的"栈切换"是"解释器状态（lua_State）交换"而非"机器栈切换"——实现简单、成本低、无栈管理负担；代价=协程执行被限制在解释器上下文（C 边界需 yield-aware、性能受解释器约束）。

以"协程状态全在 lua_State（Lua 栈+CallInfo+PC）"讲清切换=状态交换（非机器栈切换），再展开栈管理细节与"C 边界不可跨"的工程边界。

• boost::context（fiber 底层）：fiber 是"对称协程"（对称转移：任意 fiber 可把控制转移给任意 fiber（fiber::suspend/transfer））——对比 Lua 的非对称 resume/yield
• 工程价值：一、内存（大量 fiber 的栈内存与虚拟地址（共享栈只需少数栈））；二、切换（拷贝活跃栈（浅栈时拷贝小）vs 独立栈的寄存器切换）的取舍；三、对称转移使"调度器/管道"的 fiber 间直接切换简洁（任意目标）
• 限制：共享栈的"栈内容需在切换时保存"（拷贝成本随活跃栈深）、栈上数据在"切换后访问"无效（需注意跨切换的指针）、与"协程内长时间不切换的大栈帧"冲突

boost::fiber 构建于 boost::context 之上：fiber 是"对称协程"——控制转移是"对称"的：任何 fiber 可以把执行权直接转移给任何其他 fiber（fiber 的 suspend()/resume 或调度器（fiber::scheduler）），不限于"调用者-被调者"配对（对比 Lua 的非对称 resume/yield）；这使"管道/生产-消费/调度器"的"任意跳转"在语义上直接。栈模型：默认每 fiber 独立栈（分配器可配（mmap/池））；boost::context 也提供"共享栈（shared stack）"选项（shared_fixedsize_stack/shared_split_stack）：多个 fiber 复用同一块"共享机器栈"——切换机制：当前 fiber 让出时，把其"活跃栈内容"从共享栈拷贝（保存）到其私有存储（仅保存"使用的部分"（栈深）），目标 fiber 恢复时把其保存的栈内容"拷贝装载"回共享栈——即"共享栈+切换时保存/装载"。工程价值：一、内存效率——大量 fiber（万级+）：独立栈的"栈内存×N"（即使按需提交，虚拟地址与 vma 数仍大）；共享栈只需"1（或少量）个栈+各 fiber 的活跃栈保存区"（活跃栈通常远小于全栈——浅栈任务的总保存量=活跃栈深之和）——支持"海量轻量 fiber"；二、切换成本——共享栈切换=拷贝（保存+装载活跃栈），独立栈切换=寄存器级（快）——取舍：活跃栈浅（拷贝小（KB 级））时共享栈可接受，深栈（拷贝 MB 级）时共享栈退化（拷贝成本高）；三、对称转移的配合——共享栈与"对称转移"组合让"fiber 调度器"（transfer 任意目标+省栈内存）适合"大量协作式任务"（类似 Go 的"小栈多任务"思路但用"共享栈+拷贝"实现（Go 用独立小栈+增长））。限制与注意：一、跨切换的指针——fiber 在共享栈上"被切换出去后再回来"时，栈内容已装载回（可能在不同地址？boost::context 的共享栈"切换后地址变化"（保存区→共享栈的不同位置）——"指向共享栈上数据的指针"在切换后失效（必须保存在"非栈"位置（fiber 私有堆）或重新获取）——这是共享栈的著名陷阱；二、栈上大对象/深调用链——活跃栈深=拷贝量（深递归+共享栈=每切换拷贝大栈，成本高）；"不切换的长栈帧"（如持有大缓冲跨切换）与共享栈冲突（缓冲在栈上（切换后失效））；三、与"非对称需求"——共享栈常用于"对称转移+调度器"场景（任务切换频繁、浅栈），非对称（resume/yield 配对）场景独立栈更直接。工程实践：boost::fiber 的"共享栈+对称转移"适合"海量浅栈任务"（连接处理、事件分发）；深栈/长帧任务用独立栈；性能验证（切换基准：拷贝量 vs 寄存器切换）；注意栈上指针的跨切换生命周期（把跨切换数据放堆/fiber 局部存储））。

以"对称转移（任意目标）+共享栈（切换拷贝保存/装载）"讲清 boost::fiber 的模型，重点展开省内存的工程价值与"栈上指针跨切换失效、深栈拷贝退化"的限制。

• 对称转移：await_suspend 返回 handle→编译器生成"尾调用式转移"（不叠加栈帧——恢复目标协程在"当前帧"执行）
• 与普通递归差异：递归的"每次调用"都在同一调用栈上叠加帧（深度=递归深度）；对称转移的"每次转移"复用当前帧（深度恒定）——因为被挂起协程的"帧"不在调用栈上（在协程状态对象中），转移是"平级跳转"
• 关键：非对称的 resume 调用链在"C 调用栈"上（resume() 是函数调用）；对称转移把"恢复"变成"尾部跳转"（编译器保证 O(1) 栈深）

机制对比：一、非对称（asymmetric）转移的栈增长——resume() 是一个普通函数调用：A 协程执行中 resume(B)（B 在 A 的调用栈帧上运行）、B 中 resume(C)（C 在 B 的帧上）——"链式恢复"（每个协程"完成后恢复下一个"）在 C++ 调用栈上形成嵌套：栈深度=链长；若协程链无限（事件循环"任务 A 完成→恢复 B→B 完成→恢复 C→…"且链持续），调用栈持续增长——最终爆栈（这是"非对称模型+链式调度"的经典缺陷（asymmetric transfer 的"recursive resume"问题））。二、对称（symmetric）转移的机制——awaiter 的 await_suspend 返回"目标协程的 coroutine_handle"时，标准要求实现"不得增加调用栈深度"（编译器把"恢复目标"实现为"尾调用/跳转"：当前协程的帧保存（协程帧在堆/状态对象中，不占调用栈）、控制"平级"跳转到目标协程的恢复点（在"当前调用帧"上继续执行目标协程））——链式转移的调用栈深度保持常数（O(1)），无论链多长：无限 resume 链安全（不会爆栈）。三、与普通递归的差异——普通递归（函数自调用）：每次调用在调用栈叠加一帧（深度=递归深度（栈大小限制递归深度（如默认 8MB 栈≈数十万层））——递归是"同函数逐层深入"，帧必然叠加（无尾调用优化时；尾递归（tail call）可优化为 O(1)（编译器复用帧））；对称转移与"尾递归优化"本质相同：把"恢复目标协程"视为"尾调用"（当前工作已结束、无返回需要），编译器/标准保证其"不叠加帧"——差异：递归的"每层"是"同一调用栈上的嵌套执行"，对称转移的"每跳"是"不同协程对象间的平级切换（帧在协程状态中，调用栈只承载"当前活跃协程"）"。四、适用边界——非对称模型在"单次 await"（协程等待某个操作完成）下无问题（深度=1~2 层）；问题只出现在"链式调度"（协程之间互相恢复的流水线/调度器）；对称转移正是为"调度器/任务链"设计的：正确性（不爆栈）+性能（少一层返回）。工程要点：一、用"返回 handle"（对称）实现"协程完成→唤醒下一个"（asyncio 风格的调度器）；二、压测深链（百万次转移）对比栈深度（perf/栈回溯）；三、非对称实现（如手写 resume 循环）在"链式恢复"时要改造成"循环+对称转移"或"显式队列"（避免嵌套）；四、注意对称转移的"帧销毁链"（链尾销毁整链（帧由最终持有者释放））。结论：对称转移=协程恢复的"尾调用"语义（O(1) 栈深），解决"无限 resume 链"的爆栈；普通递归的栈增长是"同栈嵌套"，对称转移的恒定深度源于"协程帧不在调用栈上+恢复即跳转"）。

以"resume 是嵌套调用 vs 对称转移是尾调用跳转"讲清栈深差异，再对比普通递归的同栈嵌套，说明"帧在协程状态对象中"是恒定深度的根因。

• 每协程独立 lua_State（独立 Lua 栈+调用栈+PC）——"独立线程"（解释器线程）
• lua_yieldk：C 函数"让出"的 API——压入 yield 返回值、注册 continuation（恢复时调用）、返回特殊值给解释器——C 函数拆成"yield 前+continuation"两段
• 作用：让 C 扩展/IO 库参与协程挂起（异步化）

Lua 协程的"独立线程"本质：每个协程是独立的 lua_State（解释器实例状态）：拥有自己的 Lua 栈（TValue 数组）、调用栈（CallInfo 数组）与执行位置（PC/指令指针）——可以视为"同一 VM 内的解释器线程"（共享全局表/函数/闭包（共享 upvalue 与全局环境），但执行上下文独立）。resume/yield 时的"栈切换"：把"解释器当前执行的 lua_State"从旧协程切换到新协程——旧协程的状态（L->top、L->ci（当前函数帧）、PC）保存在其 lua_State 内；目标协程的状态恢复（解释器从目标协程的 PC/栈顶继续解释）——切换是"解释器状态交换"，无机器栈切换；resume 传参：把参数压入目标协程的 Lua 栈（作为协程函数参数/上次 yield 的返回值）；yield 返回：把 yield 参数压入"resume 者的栈"作为返回值。C 函数中 yield 的限制：C 函数帧的执行状态（C 局部变量、C 调用栈中的位置）不属于 lua_State（无法保存/恢复）——因此：a) 协程在"C 函数执行中"不能直接 yield（或调用会 yield 的 API）——报错"attempt to yield across a C-call boundary"（Lua 5.1 起对部分 API 放宽（lua_callk 等可配置））；b) 只有"yield-aware"的 C 函数能跨越：lua_yieldk(L, nresults, ctx, continuation)——作用：把"yield 返回值"压栈后"让出"（向解释器返回特殊值（LUA_YIELD），解释器挂起协程（状态保存））；协程恢复（resume）时，解释器调用 continuation（C 函数指针，传入 ctx 与 resume 传递的值）——C 函数在 continuation 中"继续剩余逻辑"：即"C 函数被拆成'挂起前部分 + continuation（挂起后部分）'"（C 层的显式续延/状态机）。配套：lua_callk/lua_pcallk（C 调用 Lua 函数时允许被调 Lua 函数 yield（挂起后经 continuation 恢复 C 调用链）、lua_getctx（continuation 中取回 ctx）。工程价值与边界：一、IO/协程库（LuaSocket 的协程模式、luv、Copas 调度器）用 lua_yieldk 实现"非阻塞让出"（C 库发起异步 I/O→yield→事件循环 resume→continuation 继续）；二、限制——C 库必须"感知协程"（未用 lua_yieldk 的调用仍不可跨）；continuation 是"手工续延"（无自动保存 C 局部状态（需通过 ctx/upvalue/闭包传递））；三、与"独立线程"的关系——协程的 lua_State 可被多个 OS 线程使用吗？Lua 状态默认非线程安全（每 OS 线程独立 lua_State；协程的"线程"是解释器级概念（同一 OS 线程内协作式）——"独立 lua_State 线程"指"解释器执行上下文"，非 OS 线程。结论：Lua 协程=同 VM 内独立解释器状态（lua_State），切换=状态交换；C 边界 yield 需 lua_yieldk+continuation（显式续延）——"C 层挂起"的工程通道））。

以"独立 lua_State=解释器线程"讲清协程本质与栈切换（状态交换），再以"C 帧不可保存→lua_yieldk+continuation 拆段"讲 C 边界限制与 API 作用。

• 协作模型：I/O 事件（epoll 就绪）→ 产生任务（把"就绪关联的 future/协程"入队）→ work-stealing 调度器执行任务
• 窃取：worker 本地队列空→ 尝试从其他 worker 队列取（victim 选择（随机/轮询/NUMA））→ 也空→检查全局队列→也空→"等待 I/O 事件"（blocking poll：epoll_wait 挂起（含超时）——I/O 事件到达即被唤醒处理（"窃取 I/O 事件"：事件=任务源））
• 关键：空闲 worker 的"最后一个选择"是进入"事件等待"（不是忙轮询）——事件循环与调度器在"等待"上合一（一个线程既是 worker 又是 reactor 等待者）

协作模型（Tokio 多线程 runtime 的典型）：每个 worker 线程的循环 = "处理本地/窃取的任务 + 处理 I/O 事件"：一、事件→任务：reactor（epoll/kqueue/io_uring）维护"fd→waker"注册表：I/O 就绪（epoll_wait 返回事件）→ 找到该 fd 关联的 waker → wake() 把对应 future/协程"推入其所属 worker 的本地队列"（或标记就绪）——I/O 事件"转化"为可执行任务；二、work-stealing 调度器执行：worker 从"本地队列 →（空则）其他 worker 队列（窃取）→（仍空）全局队列"取任务执行；任务执行中可能"发起新的异步 I/O"（注册新 interest 到 reactor）——"执行任务"与"等待 I/O"在 worker 循环中交替。三、空闲 worker 的窃取与等待：a) 窃取——本地队列空时，worker 尝试从 victim（随机/轮询选择的另一 worker）的队列尾部窃取任务（一次窃取一半/定量）：保证"某 worker 任务堆积时其他 worker 不空闲"（负载均衡）；b) 全局队列——所有 worker 本地空后检查全局队列（新任务/唤醒任务的中转）；c) "等待 I/O"——本地/窃取/全局都空时，worker 进入"阻塞等待事件"（epoll_wait（带超时）挂起）：I/O 事件到达→该 worker 被唤醒→处理就绪事件（产生任务）→继续循环——即"空闲 worker 的最后动作是等 I/O 事件"（不是忙轮询）：worker 既是"任务执行者"又是"reactor 等待者"（事件等待与任务等待合一——没有独立 reactor 线程时）。四、协同细节：a) 唤醒他人——worker 向"已阻塞在 epoll_wait 的 worker"注入事件（eventfd/wakeup 机制：新任务/跨线程唤醒时向 reactor 写 eventfd 使阻塞的 worker 醒来（重新检查队列））——"任务唤醒"与"I/O 唤醒"共用事件通道；b) 多 reactor——Tokio 多线程模式：每 worker（或每组）一个 reactor（mio 实例），I/O 事件按"fd 归属"分发；c) 平衡——"事件多、任务少"与"任务多、事件少"的动态由 worker 循环自平衡（处理完任务→等事件；事件处理完→执行任务）。工程要点：一、理解"worker 空闲=等待 epoll_wait"（不是空转）——"CPU 使用率低但延迟高"排查：事件唤醒路径（waker→队列）与 epoll 等待的交互；二、"窃取"与"I/O 归属"的冲突——被窃取的任务发起 I/O 时注册到"当前 worker"的 reactor（fd 与 worker 的亲和（Tokio 的"任务迁移后 I/O 归属变化"由 mio 的注册表管理（fd 可被任意 worker poll——需线程安全（mio 的注册是线程安全的）））；三、公平——窃取在"任务不均衡"时发生；事件驱动的任务（I/O 密集）走"就绪→wake"路径，CPU 密集任务走"队列"路径。结论：协作=事件（epoll）→任务（waker 入队）→调度（窃取+等待）；空闲 worker"先窃取、再等事件"——事件循环与工作窃取在 worker 循环中统一）。

以"事件→任务（waker）、任务→执行（窃取）、全空→等事件（epoll_wait+eventfd 唤醒）"的三段循环讲清协作模型与空闲行为。

• 规避：非阻塞封装（事件循环：fd 设 O_NONBLOCK+epoll 等待）、异步 I/O（io_uring）、阻塞操作外派（线程池）
• 运行时识别"可阻塞调用"（Go 的 syscall 让渡 P、Tokio 的 spawn_blocking、Java VT 的 pin 处理）
• 工程纪律：协程内禁用阻塞调用（除非库提供异步版本）

原因：协程在 OS 线程内协作式调度——线程的"执行权"是共享的：任一协程执行"阻塞系统调用"（阻塞 socket read（无数据时睡眠）、阻塞 sleep（nanosleep）、同步文件 I/O、阻塞锁（futex））时，OS 把"整个线程"置为睡眠（等待该调用完成）——线程上"就绪但未运行"的其他协程全部停摆（调度器（用户态）无法运行）——表现为"一个协程阻塞=整线程卡死"（协作式调度的核心纪律：任何阻塞都是全局事故）。规避（运行时的三层机制）：一、非阻塞封装（事件循环）——把"阻塞调用"改写为"非阻塞调用+就绪等待"：fd 设 O_NONBLOCK（read 返回 EAGAIN 而非睡眠）→ 协程"挂起"（把"等待该 fd 可读/可写"注册到事件循环（epoll））→ 让出控制权（其他协程运行）→ fd 就绪时事件循环唤醒该协程（重新发起非阻塞读）——"阻塞语义"由"事件就绪+协程恢复"模拟（Go 的 netpoller、Tokio 的异步 IO 原语、Java NIO 的实现方式）；二、异步 I/O（io_uring）——不阻塞的"提交-完成"模型：协程提交请求后挂起（等待完成事件），内核异步执行（完成队列通知）——磁盘/网络统一（Go 的实验性后端、Tokio 的 io_uring、SPDK 类）；三、阻塞外派（线程池）——"确实会阻塞"的操作（同步文件 IO（旧实现）、第三方阻塞库、CPU 密集但需让出）交给"专用阻塞线程"执行：协程提交任务到线程池并挂起，线程池线程阻塞执行（不占事件线程），完成后经"完成通知"唤醒协程（Go 的 spawn_blocking？Go 无此 API（其文件 IO 已异步化；C++/Tokio 的 spawn_blocking、Java VT 的 carrier 外派、Rust 的 rayon 结合））；运行时还配合"识别"：Go 的"阻塞 syscall 让渡 P"（M 带 G 进入内核、P 转给其他 M——协程"不在线"但线程被让出（其他 G 仍可运行）——这是"OS 线程级"的规避（非"协程级"：syscall 期间该 G 无法调度但其他 G 继续））；Java VT 的"pin 检测与 carrier 替换"。工程纪律与判断：一、协程内"禁止直接使用阻塞 API"（读源码/库文档确认异步版本）；二、"阻塞调用"识别——可能阻塞的系统调用清单（read/write（常规文件除外？块设备 IO 在内核同步执行（阻塞））、connect/accept（无 O_NONBLOCK 时）、sleep、mutex、waitpid、同步 fsync）——用"非阻塞+epoll"或"线程池"替代；三、检测——运行时监控"线程睡眠中的协程"（pprof 的 syscall 等待、Tokio 的 blocking 检测（block_in_place 的警告））；四、性能——"阻塞外派"的线程池大小（避免线程风暴）与"非阻塞封装"的覆盖：库必须全异步（否则"传染"（一个阻塞调用破坏整个事件循环））。结论：阻塞=整线程停摆（协作式）；规避=非阻塞封装（事件循环）、异步 I/O（io_uring）、阻塞外派（线程池）三选一（按调用类型），配合运行时的"syscall 让渡/pin 处理"。

以"阻塞调用使整线程睡眠→所有协程停摆"的机制开题，再分非阻塞封装/io_uring/线程池三层给规避手段与运行时配套（syscall 让渡、pin 检测）。

• 协作式协程无抢占：长任务独占线程——需要"信号化抢占"（runtime 主动打断）
• 关键：安全点（信号打断只能发生在"指令边界"，注入的让出必须"安全"（栈/GC 状态一致）——Go 的 async preemption是"信号化抢占"的现代实现（SIGURG）；老实现（SIGVTALRM/ SIGALRM 定时器）在"timer tick"触发）
• 边界：syscall boundary——阻塞 syscall 无法用信号打断（信号递送在 syscall 返回时）——syscall 抢占靠"让渡 P/超时回收"（Go 的 sysmon）

协作式协程（无抢占点）的"长任务独占线程"问题：纯协作模型下，一个不主动让出的任务（长循环、密集计算）会永久占住线程——需要"运行时强制打断"（抢占）。信号化抢占的机制：一、触发源——a) timer tick：运行时安装定时器（setitimer（ITIMER_VIRTUAL：SIGVTALRM——仅进程 CPU 时间（虚拟时间）触发；ITIMER_REAL：SIGALRM 墙钟时间））周期触发信号（老方案（如早期 Go 的抢占设计讨论、部分协程库）：每 tick 检查"当前任务是否超时（运行超过时间片）"→ 是则抢占；b） 调度器主动：runtime 决定"该让出了"（时间片到期/GC 需要）→ 显式向目标线程发送信号（pthread_kill(SIGURG)（Go 的 async preemption 用 SIGURG——选择"应用通常不用的信号"（Go 1.14+：SIGURG 专用于抢占（不与用户信号冲突））；SIGVTALRM/SIGPROF 用于 profile（Go 的 CPU profile 用 SIGPROF））。二、处理（信号处理程序中的抢占注入）——信号递送到目标线程时打断其当前指令流（保存现场（寄存器））→ 处理程序检查"当前执行位置是否安全点（safe point）"：是（如函数序言/栈扩容检查点/插桩的可抢占指令）→ 注入抢占（把当前任务标记为"被抢占"并让出（保存协程上下文、调度器切换到其他任务））；非安全点（汇编无栈间隙、cgo、无法保存的指令）→ 放弃本次抢占（等下次信号/下个安全点）。三、syscall boundary——阻塞 syscall 中"信号递送延迟"（syscall 返回后才处理信号）：无法用信号打断"正在阻塞的系统调用"（信号不能解除阻塞（除非 SA_RESTART 语义））——因此"syscall 中的线程"不靠信号抢占：Go 的处理是"syscall 让渡"（阻塞超时（10ms 阈值）由 sysmon 把该 M 的 P 回收——"syscall 边界"的抢占=让渡 P（其他 G 可运行），而非打断 syscall 本身（syscall 返回后 G 重新找 P）。四、现代实现（Go 1.14+ async preemption）：信号（SIGURG）由 runtime 在"需要抢占时"发给目标 M：处理程序在安全点注入（配合"编译器插桩的抢占检查点（栈扩容检查/函数序言）"）——"timer tick + 信号"的工程组合：runtime 周期性检查（sysmon 约 10ms 粒度）发现"超时未让出"的 G→发信号（比老式"纯定时器信号"更精准（按需触发））。信号化抢占的边界与代价：一、信号处理开销（保存/恢复现场、安全点检查（微秒级））；二、安全点限制（无安全点的代码（汇编/内联汇编循环）无法被信号抢占（需"协作式检查点"配合或接受"不可抢占段"）；三、与用户信号冲突（选择"预留信号"（SIGURG/SIGVTALRM）并文档化；用户自定义 handler 冲突）；四、实时/确定性（信号抢占的时机不可完全预测——实时场景慎用）。对比："协作式检查点抢占"（编译器在调用点/循环回边插入"检查并让出"）vs"信号化抢占"（运行时打断）——前者可预测但"无检查点代码不可打断"，后者打断力强但开销与安全点约束（Go 两者结合：检查点插桩+信号注入））））。

以"定时器/主动信号触发→安全点注入抢占"讲信号化抢占机制，分别展开 SIGURG（Go 按需）与 SIGVTALRM（老式 tick）的用法、syscall 边界的让渡替代与安全点/开销边界。

• epoll 的瓶颈：每次 wait 一次系统调用返回就绪事件，随后仍需对每个 fd 发起 read/write 系统调用——"两段式"路径（poll + 实际 IO）
• io_uring 的批处理：一次 io_uring_enter 提交多个 SQE、处理多个 CQE；SQPOLL 模式连进入系统调用都可省去
• 协程运行时视角：epoll 需"poll 事件→再派发异步 IO"两跳；io_uring 把"等待就绪"与"执行 IO"合并为一个提交

epoll 在协程运行时（Tokio/Go netpoller 一类）的路径是"两段式"：协程想读某个 fd 时，先把它注册到 epoll（epoll_ctl），epoll_wait 返回"可读"事件后，协程再发起实际的 read() 系统调用——即"就绪检测"与"数据搬移"是两次独立的内核往返，每次完成一个 IO 都要两次系统调用（read 一次、epoll_wait 一次），且每次 epoll_wait 都要经历一次用户态/内核态上下文切换。io_uring 把二者合并：协程把"读 fd X"的请求（SQE）直接写入提交队列（通过 mmap 共享内存，无需系统调用），一次 io_uring_enter 提交多个 SQE，内核异步完成，完成结果写入完成队列（CQE），用户态通过 mmap 直接读取完成队列——完成多个 IO 只产生一次系统调用（甚至通过 SQPOLL 模式由内核线程轮询提交队列，连 io_uring_enter 都可省去）。这样每个 IO 的系统调用次数从"2 次（read + epoll_wait）"降为"分摊到一批的 1/批次数"，上下文切换次数也随之显著下降。对协程运行时而言，epoll 模型下协程通常要"先挂起等就绪事件、醒来后再发起实际 IO"，逻辑上分两步；io_uring 一次提交即完成"就绪等待+数据搬移"，协程只需挂起等待完成队列事件即可，调度路径更短、事件通知更少。工程要点：一、io_uring 的批量提交天然契合"多协程并发 IO"的运行时长（多个协程的 SQE 可合并为一次 enter）；二、SQPOLL 模式适合持续高吞吐、IO 频繁的场景，省去系统调用，但需额外内核线程与 CPU 占用；三、需要内核与 liburing 支持，且 fd 类型限制（不支持所有设备的异步路径）决定了并非所有 IO 都能受益。

从"epoll 两段式 vs io_uring 单次批量提交"的路径差异切入，先讲系统调用与上下文切换如何被减少，再落到协程运行时调度路径的简化与 SQPOLL 等边界。

• 阻塞→就绪通知：fd 设 O_NONBLOCK，read 返回 EAGAIN 时把 goroutine 挂起并注册到 epoll，就绪后唤醒
• 调度器协作：挂起的 goroutine 让出 P，唤醒后重新入队
• 关键数据结构：netpoll 的 fd→g 映射、pollDesc、runtime 的 netpoll 循环（sysmon 与运行中的 M 都会触发）

Go 的网络 I/O 语义在用户态是"同步阻塞"的（net.Conn.Read 会阻塞当前 goroutine），但底层通过 netpoller 实现为"非阻塞 + 就绪通知"：网络 fd 以 O_NONBLOCK 打开，goroutine 调用 Read 时，若 fd 无数据，read 返回 EAGAIN（而非睡眠）——此时 netpoller 把该 goroutine 挂起（标记为"等待这个 fd 可读"），让出当前的 P（其他 goroutine 可运行），并把 fd 注册到 epoll 的就绪监听集合。当 fd 真正可读时，epoll_wait 返回就绪事件，netpoller 根据"fd→等待它的 goroutine"映射找到对应的 g，将其唤醒重新投入调度队列。这样 goroutine 看到的仍是"阻塞式"编程模型，而底层实际是异步事件驱动。调度器配合：netpoller 的 epoll_wait 通常在"M 空闲时"或"sysmon 定时"被调用，挂起的 goroutine 不占 P，就绪后由空闲 M 的 netpoll 循环取回。工程要点：一、netpoller 把"一个 goroutine 一个系统调用"的阻塞开销转换为"事件驱动"的共享轮询，使数百万 goroutine 只依赖少量 epoll 描述符；二、epoll 就绪→g 唤醒之间通过"运行队列"衔接，避免忙等；三、文件 I/O（非网络）早期不走 netpoller，Go 1.9+ 引入 pollable 文件后缓存文件走异步路径，磁盘同步 IO 仍可能阻塞；四、netpoller 是 Go 实现"高并发低开销网络服务"的基石。

以"非阻塞 fd + EAGAIN → 挂起 g 并注册 epoll → 就绪唤醒"的事件链讲清 netpoller 如何把阻塞语义翻译为异步通知，再说明调度器挂起/唤醒与 epoll_wait 的衔接。

• epoll：就绪通知（readiness）——只告诉"可读/可写"，数据搬移仍由用户再次发起
• 差异对运行时的影响：epoll 需"就绪→再读"两段；IOCP 一次性携带数据，减少二次系统调用
• IOCP 的并发绑定（GetQueuedCompletionStatus）与线程池模型、epoll 的"事件循环"单线程模型

epoll 是"就绪通知（readiness-based）"模型：它只报告 fd 处于"可读/可写"状态，具体的数据搬移仍需用户再发起一次 read/write 系统调用——因此 Linux 上的协程运行时通常要"等就绪事件、再执行 IO、再等完成"两步。IOCP 是"完成通知（completion-based）"模型：用户一次提交（如 WSARecv/ReadFile）后，数据搬移由 OS 异步完成，完成后把结果（含数据量、错误）放入完成队列，用户通过 GetQueuedCompletionStatus 取回——无需二次系统调用。对协程运行时设计的影响：一、提交与完成端口——IOCP 要求 IO 与完成端口（Completion Port）绑定，完成事件投递到端口，多个工作线程可并发 GetQueuedCompletionStatus 取回（天然支持线程池并发）；epoll 通常是单线程/每线程各自的 epoll 实例，事件需自己分发到 worker。二、运行时的"协程挂起点"——epoll 模型下协程挂起等待"就绪"，醒来还要再做一次 IO；IOCP 模型下协程挂起等待"完成"，完成时数据已在用户缓冲，协程醒来直接消费。三、IOCP 的 OVERLAPPED 结构携带 per-IO 上下文，完成回调可携带协程句柄，天然支持"基于完成回调"的协程恢复；epoll 需维护 fd→协程的映射表。四、线程亲和——epoll 的 fd 与线程绑定较紧（通常一个线程一个 epoll），IOCP 完成事件可被任意绑定线程取回，协程迁移更自由。工程要点：Windows 上的协程运行时（如 Tokio 的 IOCP 后端、Go 的 netpoll 在 Windows 上用于 IOCP）按"完成通知"设计，通常直接在一次调用中携带协程恢复信息；Linux 上则需"就绪+再读"两跳，这也是 io_uring 引入 Linux 后向"完成者模型"靠拢的原因。

对比"就绪通知 vs 完成通知"的本质差异，再落到协程运行时在挂起点、线程模型、上下文携带上的不同设计，最后联系 io_uring 的演进趋势。

• 协程（有栈）栈：堆上分配，guard page 是否可用、如何检测溢出
• 动态增长协程栈（Go）的栈拷贝 vs 固定栈的 guard page
• 差异：guard page 的映射开销、页表压力、SIGSEGV 处理路径

OS thread 栈由内核或运行时分配在进程地址空间，栈底通常放置一个 guard page（不可访问的页），当栈向低地址增长越过 guard page 时触发页错误并转化为 SIGSEGV——这是"硬件辅助"的栈溢出检测，代价是每个线程占一个额外页（4KB 映射），且栈区域整体预留（通常 8MB 虚拟空间）。有栈协程（如 boost::fiber、libaco 的独立栈）的栈在堆上分配，同样可以尾随 guard page 检测栈溢出——但细节不同：一、guard page 要在栈上"打洞"（mmap 一个不可访问页），增加映射管理开销，且大量协程（每协程 1MB 栈）会放大页表/映射压力；二、SIGSEGV 处理路径——线程栈溢出时内核在缺页路径直接发 SIGSEGV（默认终止）；协程栈溢出时（若用 guard page）同样触发 SIGSEGV，但运行时可安装 handler 捕获后在"栈溢出处理器"中做扩容或终止，不过 handler 需要尽量少的栈空间（guard page 也保护 handler 自身栈）；三、Go 的动态栈没有 guard page——它以"栈拷贝"实现生长（栈满时分配更大栈并拷贝、搬移指针），因此不依赖 guard page 检测，而是通过"栈顶探测（栈扩容检查）"插桩在函数序言判断是否需要扩容；四、固定栈（固定 1MB 不增长）在栈溢出时若没有 guard page，会静默写越界（破坏堆），有 guard page 则能可靠触发 SIGSEGV。工程差异总结：guard page 提供"廉价可靠的溢出检测"，但每协程多一个页映射、增大页表和 TLB 压力；动态栈通过拷贝取消 guard page 需要，但引入拷贝与指针搬移开销。结论：选择固定栈+guard page（检测可靠、可静态预估）还是动态栈（省页、弹性）取决于协程数量与栈深度需求。

先讲 OS thread 栈的 guard page 机制，再对比有栈协程固定栈的 guard page 开销与 SIGSEGV 处理，最后讲 Go 动态栈放弃 guard page 改用栈拷贝的取舍。

• 无栈协程：状态机/生成器，无独立栈，切换只保存局部状态（少量寄存器）
• 开销对比：有栈切换涉及栈指针切换、可能缓存失效；无栈切换更轻但灵活性受限
• 内存：有栈预分配栈（固定/动态），无栈几乎零栈开销

有栈协程（stackful，如 boost::fiber、libaco、Go goroutine）给每个协程维护独立的执行栈，切换（yield/resume）本质是完整的上下文切换：保存当前寄存器（含栈指针 RSP/SP）、恢复目标协程的寄存器与栈指针，通常数十到上百条指令，且切换后可能造成 cache 与 TLB 失效（新栈区域不在缓存中）。无栈协程（stackless，如 C++20 coroutine、Rust async、Python generator）没有独立栈，挂起时把局部变量/状态固化为"状态机"存于堆上的 frame（coroutine frame），切换（resume）只是恢复少数状态字段并跳转到对应状态机的下一段代码——开销通常是几个寄存器保存 + 分支跳转，远小于有栈切换。对比维度：一、切换开销——无栈（纳秒级、可内联）显著低于有栈（完整上下文切换）；二、内存——有栈每协程预分配栈（Go 2KB 起动态增长；固定栈可能 1MB），无栈只占用 frame（近似只存局部变量，通常远小于栈）；三、灵活性——有栈协程可嵌套调用、可用在任意调用深度（像真实线程），无栈协程挂起点受限制（不能"跨任意函数深度"挂起，C++20 要求挂起发生在协程函数内，且不能从普通函数中挂起）；四、栈拷贝——有栈动态栈（Go）在栈满时需拷贝栈并搬移指针，无栈无此问题；五、尾调用优化——有栈协程的无休止 resume 可能栈增长，无栈用对称转移避免。工程结论：追求极致性能与轻量（异步 IO 密集、大量并发）用无栈协程；需要"真实线程式"的嵌套调用、可挂在任意函数深度、或需要抢占/栈增长时用有栈协程。

从"是否维护独立栈"这一根本差异切入，分别量化切换指令数与内存开销，再对比灵活性、挂起点限制与栈增长，给出两种模型的适用场景。

• 饥饿原因：长任务（CPU 密集、死循环）不让出，其他协程和 IO 事件永远得不到执行
• 解决：抢占（信号化/协作式检查点）与调度配额（时间片）
• Go 的 async preemption、syscall 让渡、Tokio 的 yield_now、调度配额

在事件循环/用户态协作式调度中，协程共享一个（或少数）OS 线程：若某个协程不主动让出（长时间运行、死循环、CPU 密集计算），它就一直占住线程，其他就绪协程以及待处理的 IO 事件（epoll 的完成回调）都无法执行——即"饿死"其他协程。原因在于协作式调度没有强制抢占，执行权完全依赖协程主动 yield。运行时解决饥饿的手段：一、抢占（preemption）——a) 协作式检查点：编译器在函数调用点/循环回边插入"检查并让出"代码（如 Go 的预展开检查点），协程在这些点主动检查调度请求；b) 信号化抢占：运行时通过定时器（timer tick）或主动发信号（Go 用 SIGURG）打断运行过久的协程，在安全点注入让出（Go 1.14+ 的 async preemption）。二、调度配额（时间片）——运行时记录每个协程已运行的时间，超过配额（如 Go 的 10ms 量级）则标记为"应让出"，在下一个安全点让出；Tokio 的"预算（budget）"/"yield_now"提示协程在长时间操作中主动让出。三、事件循环配合——IO 事件与任务执行交错，防止"任务堆积导致事件延迟"。Go 的具体机制：sysmon 每约 10ms 检查，发现 G 运行超时则发 SIGURG 抢占；协程在安全点让出后重新入队，保证公平轮流。工程要点：一、纯协作式（无抢占）的运行时（部分协程库）必须依赖用户主动 yield，易被"恶意长任务"卡死；二、抢占需要"安全点"支持（编译器配合），否则无法在任意代码打断；三、调度配额让"公平"可用时间度量，防止单协程无限占用。

先讲协作式调度下"长任务不让出→饿死他人"的根因，再分别给抢占（协作式检查点+信号化）与调度配额两类解法，最后落到 Go 的 sysmon/async preemption 与 Tokio 预算的具体实现。

• 结构化并发：协程形成父子树，父协程取消/退出时自动取消子协程
• 协作式取消：协程需检查 isActive/cancellation 挂起点（suspend 函数）才响应
• 与线程池 shutdownNow 差异：shutdownNow 中断线程（interrupt），不保证协同清理；结构化取消是层级、可传播的

Kotlin 结构化并发把协程组织成父子层级：父协程（scope 或 job）等待所有子协程完成，子协程继承父协程的 Job 结构。当父协程被取消（cancel）时，取消状态沿"父子树"向下传播到所有子协程——每个子协程对应的 Job 变为取消状态，运行中的子协程在下一次"取消检查点"（suspend 函数、isActive 检查、yield 等）抛 CancellationException，从而结束执行。这是"协作式取消"：协程不会立即被强制终止，而是在可取消挂起点抛出取消异常；finally 块仍可执行清理（释放资源），但协程继续执行挂起操作会再次抛 CancellationException（除非用 NonCancellable 上下文）。这与线程池 shutdownNow 有本质差异：一、层级传播——shutdownNow 只是向池中线程逐个调 interrupt()，没有"父子/结构"概念，无法表达"某个任务的子任务"关联；Kotlin 取消沿协程树传播，结构化且可追溯。二、协作式 vs 中断式——shutdownNow 用线程中断标志（Thread.interrupt），仅当阻塞调用响应中断（如 wait/sleep 抛 InterruptedException）才生效，且不自动清理；Kotlin 用 CancellationException 在挂起点抛出，配合 finally 清理。三、生命周期保证——结构化并发保证父协程 cancel 后所有子协程一定也会被取消（除非在 NonCancellable 中），线程池 shutdownNow 无法保证"子任务"被一并取消。工程要点：一、取消传播让"超时/取消父任务"能级联终止所有子任务，避免资源泄漏；二、子协程可通过 Job.isCancellable 或 NonCancellable 包裹不可取消的清理段；三、取消是正交于"异常"的——CancellationException 是取消信号，应在 finally 中配合清理。

先讲结构化并发的父子结构，再讲取消沿树传播与 CancellationException 的协作式机制，最后对比线程池 shutdownNow 的中断式模型，突出层级与协作式差异。

• 共享栈：多个协程共享一块栈，切换时需把当前协程栈内容拷贝到其私有存储再换入
• 开销对比：独立栈切换快（无拷贝），共享栈切换有拷贝成本但内存占用低
• libaco 的实现：默认独立栈，共享栈用于大量协程场景

libaco 是一个有栈协程库，支持两种栈策略。独立栈（separate stack）：每个协程分配独占的栈（通常默认 1MB 或可配置），切换时只需交换栈指针（RSP）并保存/恢复寄存器，无需搬移栈内容——切换开销极小（纯寄存器切换），协程数不受共享栈限制，但内存占用按协程数线性增长。共享栈（shared stack）：多个协程共享一块栈区域，同一时刻只有一个协程使用该栈；切换时，挂起的协程必须把"当前栈上其活跃部分"拷贝到其私有存储（如私有小栈或堆），换入的协程再把其私有存储拷贝回共享栈——切换开销包含"栈内容拷贝"，随栈的使用深度增长（活跃栈帧越多拷贝越大），但内存占用低（共享一块栈，适合大量协程但栈深度小的场景）。工程对比：一、独立栈切换快、无拷贝、栈深度不受共享限制，适合协程数适中、栈深变化大的场景；二、共享栈内存省、但切换引入拷贝开销，且栈深度受限（超过共享栈会溢出），适合"大量协程、栈浅"的场景；三、libaco 默认用独立栈，共享栈作为可选策略以节省内存。结论：独立栈用"切换开销换内存"，共享栈用"拷贝开销换内存"，二者是"切换速度 vs 内存占用"的权衡。

分述独立栈与共享栈的切换机制（是否拷贝栈内容），对比切换开销与内存占用，最后落到 libaco 的默认策略与适用场景。

• fiber_local 数据：类似 thread_local 但按 fiber 隔离的存储
• work-stealing：多线程调度器下空闲线程窃取其他线程队列的 fiber
• 工程价值：负载均衡、缓存友好、避免假共享

boost::fiber 是有栈协程（用户态线程）库，其调度器在单线程下是协作式（fiber 主动让出），支持多线程调度器（use_scheduling_algorithm）时可用 work-stealing：每个 OS 线程维护一个 fiber 就绪队列，协同调度；当某线程队列为空时，可从其他线程的队列中"窃取" fiber 执行，实现负载均衡——避免"某线程忙、另一线程空"的不平衡，提升多核利用率。fiber_local 数据（boost::fibers::fiber_specific_ptr）提供按 fiber 隔离的存储，类似 thread_local 但以 fiber 为粒度：fiber 切换时，fiber_local 数据随之切换，保证每个 fiber 访问自己的副本。工程价值：一、work-stealing 让多线程调度器动态平衡，适合"任务不均衡、协程数大"的场景；二、fiber_local 免去手工传递上下文，把"按 fiber 隔离的状态"（如连接句柄、事务上下文）交给库管理，避免全局共享的锁竞争；三、fiber_local 与 thread_local 的区别——thread_local 在 OS 线程内共享，fiber 切换时不会切换 thread_local 值，而 fiber_local 随 fiber 切换，避免"同一线程上不同 fiber 错误共享 thread_local"的 bug。结论：work-stealing 提供多核负载均衡，fiber_local 提供 fiber 粒度的隔离存储，二者共同支撑"高并发、每协程独立状态"的工程需求。

分述 work-stealing 调度器（多线程队列窃取）与 fiber_local（按 fiber 隔离存储）的机制，再讲各自的工程价值与 thread_local 的区别。

• co_await：挂起当前协程，等待 awaiter；co_yield：向调用方产出一个值并挂起
• 机制：编译器把协程体转换为状态机，frame 存局部变量
• 性能开销：分配 frame（堆）、挂起/恢复的少量指令、无栈切换轻量

C++20 协程是无栈协程（stackless），由编译器将协程体转换为状态机。协程首次调用时分配一个 coroutine frame（通常在堆上，存储局部变量、参数、promise_type 对象、挂起点状态），返回一个 coroutine_handle 指向该 frame。co_await expr 是核心挂起机制：对 expr 求值得到 awaiter，调用 awaiter.await_ready() 判断是否立即可继续；若未就绪，调用 await_suspend(handle) 挂起协程（把控制权交还调用方，并在适当时候通过 handle.resume() 恢复），恢复时调用 await_resume() 取得结果。co_yield value 等价于 co_await promise.yield_value(value)，向调用方产出一个值并挂起；调用方通过生成器/迭代器驱动 resume 取下一个值。性能开销：一、frame 分配——默认在堆上（malloc），是主要开销，可用分配器优化（自定义 operator new 或 arena 复用）；二、挂起/恢复——保存/恢复协程执行位置（state 索引）与少量状态，通常是几十条指令，远低于有栈协程的完整上下文切换；三、无栈——不切换栈指针，缓存友好；四、可内联——若 frame 能分配在栈上（编译器优化/小 frame）或直接内联，开销进一步降低。工程要点：co_await 的三 stage 协议（await_ready/await_suspend/await_resume）让挂起可定制（如对异步 IO 挂起、对完成事件恢复）；co_yield 用于生成器模式；性能上 frame 分配是主要成本，需用复用/池化缓解。

先讲 C++20 无栈协程的 frame 与 promise_type 结构，再分别讲 co_await（三 stage 协议）与 co_yield（值产出）的机制，最后量化 frame 分配与挂起/恢复开销。

• preempt 状态：M 被标记为"应抢占"，G 在安全点让出
• 工程价值：解决协作式调度被长任务卡死，支持 GC 等待、公平调度
• 安全点：函数序言/栈扩容检查等

Go 1.14 之前，goroutine 采用协作式抢占（仅在函数调用点/栈扩容检查点让出），一个不主动让出、且不触发 GC 检查的密集循环会"卡死"整个 P，导致 GC 无法推进、其他 goroutine 饿死。Go 1.14+ 引入异步抢占（async preemption）：当 sysmon 检测到某 goroutine 运行超过阈值（约 10ms 量级）或 GC 需要 stop-the-world 时，runtime 向运行该 goroutine 的 M 发送 SIGURG 信号；信号处理程序在该 M 的"安全点"（通常是函数序言、可抢占的指令位置、栈扩容检查点）注入抢占——把当前 M 标记为 preempt（应被抢占），中断当前 goroutine 的执行并让出，使 P 可被回收用于 GC 或调度其他 goroutine。preempt 状态（M 被标为需要抢占）在 runtime 中的工程价值：一、打破"协作式死锁"——长任务不再能无限占用 P，GC 的 stop-the-world 能及时推进；二、公平调度——超时 goroutine 被强制让出，其他 goroutine 得到执行机会；三、与 syscall 让渡互补——syscall 阻塞靠"让渡 P"（sysmon 回收 P），信号抢占用于"CPU 密集"场景；四、安全点约束——抢占只能发生在安全点（汇编/无栈间隙等不可抢占代码需其他机制配合），不能在任意指令处打断。工程要点：async preemption 用"预留信号（SIGURG）+ 安全点注入"实现，避免用户信号冲突；信号处理开销（微秒级）换取 GC 可推进性与公平。

先讲 Go 1.14 前协作式抢占的"卡死"问题，再讲 SIGURG 信号与安全点注入的 async preemption 机制，最后落到 preempt 状态对 GC、公平调度与 syscall 互补的工程价值。

• 取消传播：父取消/异常时级联取消子任务
• 防止泄漏：子任务不会在父作用域之后继续运行（除非显式 scope 逃逸）
• JEP 462（Java 结构化并发）、Kotlin coroutineScope 的实现

结构化并发（JEP 462 的 StructuredTaskScope、Kotlin 的 coroutineScope/supervisorScope）把并发任务组织成"父作用域"结构：子任务在父作用域内创建，父作用域在退出前必须等待所有子任务完成（或取消），从而保证"子任务不会泄漏到父作用域之外"。取消传播语义是防止泄漏的关键：一、父作用域取消（异常、超时、外部 cancel）时，取消状态沿"子任务树"传播，每个子任务被级联取消（Kotlin 抛 CancellationException，Java 通过 StructuredTaskScope 的 shutdown/取消）；二、子任务在挂起点/取消检查点响应取消并尽早终止，父作用域因此能及时返回，不会因为子任务挂起而永久阻塞；三、结构化保证"父不返回直至子完成或取消"——即使子任务忽略取消，父作用域也能在等待（join）后决定是否退出，避免"孤儿任务"继续运行。与线程池/非结构化并发的差异：非结构化方式（ExecutorService 手动 submit）子任务与父无生命周期关联，父可直接返回、子任务在后台继续运行（泄漏）；结构化并发强制父子绑定，父的完成/取消语义自动覆盖子任务。防止泄漏的三层保证：一、生命周期嵌套——子作用域在父作用域内，父退出时子作用域必然结束；二、取消传播——父取消首先中断子任务；三、等待（join）——父作用域退出前等待所有子任务完成，确保没有"游离子任务"。工程要点：JEP 462 的 StructuredTaskScope 用"任务泄漏"检测（shutdown 后未 join 的任务）；Kotlin 用 coroutineScope 实现"子任务全部完成或失败才返回"。

从"子任务生命周期与父作用域绑定"的结构化原则讲起，再落到取消传播与 join 等待如何保证子任务不泄漏，最后对比非结构化线程池的孤儿任务风险。

• 用户态调度器：协程在用户态队列切换，不依赖内核线程调度
• 协同：协程发起 IO → 挂起注册事件 → 就绪/完成事件唤醒协程 → 重新调度
• 用户态调度与 IO 后端的结合（Tokio/Go/io_uring 后端）

用户态调度器把协程（或任务）在用户态队列中调度，避免每个协程一个内核线程的高开销；但协程常需执行 IO，此时必须与内核的 IO 后端协作。epoll 驱动的调度：协程发起读，把 fd 设为非阻塞并注册到 epoll，协程挂起（让出线程）；一个线程阻塞在 epoll_wait，事件就绪后按 fd→协程映射唤醒对应协程，将其投入就绪队列，由调度器挑选执行——"就绪通知驱动协程恢复"。io_uring 驱动的调度：协程把 IO 请求（SQE）提交到共享内存的提交队列，一次性 io_uring_enter 提交多个，内核异步完成，完成队列（CQE）产生完成事件；协程挂起等待完成，用户态轮询完成队列（或 IOPOLL）或等待完成事件唤醒——"完成通知驱动协程恢复"，且一次提交多个、减少系统调用。协同要点：一、事件循环作为"调度器的唤醒源"——空闲线程阻塞在 epoll/io_uring 等待上，IO 事件到达即是"新任务产生"；二、用户态队列与 IO 事件队列通过"唤醒"衔接（把就绪协程 push 到运行队列）；三、io_uring 相比 epoll 可减少"就绪→再读"两跳，且支持批量提交，适合高并发 IO 密集的协程运行时。工程结论：用户态调度提供"低成本协程"，epoll/io_uring 提供"高效 IO 事件"，二者结合构成现代异步运行时（Tokio 的 epoll/io_uring 后端、Go 的 netpoller 逻辑）的核心。

先讲用户态调度器的队列与切换，再分别讲 epoll（就绪通知）与 io_uring（完成通知+批量）如何唤醒协程，最后落到事件循环与调度队列的衔接。