C++20 协程从入门到网络服务

C++20 协程从入门到网络服务：手写轻量异步调度器，对比线程池性能差距

一、开篇：为什么 C++20 协程值得你现在就学

2026 年了，C++20 协程早已不是实验室里的玩具。从阿里云函数计算服务的生产改造，到 Boost.Asio 1.70+ 的全面拥抱，协程正在重新定义高性能服务器的编程范式。

传统线程模型在十万级并发面前已经喘不过气------每个线程独占 1~8MB 栈空间，上下文切换需要陷入内核态，一次切换耗时数千 CPU 周期。而协程，把这一切打回了用户态。

协程不是线程的替代者，而是线程的解放者。 少量线程承载大量协程，才是现代高性能 C++ 程序的标准姿势。

二、C++20 协程底层：三把钥匙打开异步世界

C++20 协程不是语言层面的"线程替代"，而是编译器生成状态机的语法糖。要掌握它，只需理解三个核心组件：

组件	角色	类比
`promise_type`	协程的"大脑"，控制初始/最终挂起、返回值、异常处理	导演
`coroutine_handle`	协程的"遥控器"，手动触发 resume() 或 destroy()	场记板
`awaiter`	连接协程与异步事件的"桥梁"，定义挂起/恢复逻辑	场务

协程函数体内使用 co_await、co_yield 或 co_return 任一关键字，编译器就会将其转换为带有 promise_type 的状态机。协程帧（Coroutine Frame）存储在堆上，规模通常仅几十 KB------相比线程栈的 1MB，是 1/30 的内存占用。

三、手写一个轻量协程调度器

废话少说，直接上代码。我们实现一个单线程 FIFO 调度器，支持协程的挂起与自动恢复。

arduino 复制代码

cpp
#include <iostream>
#include <coroutine>
#include <queue>
#include <functional>

// ========== 1. Task 类型：协程的返回对象 ==========
struct Task {
    struct promise_type {
        Task get_return_object() {
            return Task{std::coroutine_handle<promise_type>::from_promise(*this)};
        }
        std::suspend_never initial_suspend() { return {}; }  // 立即执行
        std::suspend_always final_suspend() noexcept { return {}; }  // 结束时挂起
        void return_void() {}
        void unhandled_exception() { std::terminate(); }
    };

    std::coroutine_handle<promise_type> handle;

    explicit Task(std::coroutine_handle<promise_type> h) : handle(h) {}
    ~Task() { if (handle) handle.destroy(); }

    Task(const Task&) = delete;
    Task(Task&& other) : handle(other.handle) { other.handle = nullptr; }

    void resume() { if (handle && !handle.done()) handle.resume(); }
    bool done() const { return handle.done(); }
};

// ========== 2. Scheduler：调度器核心 ==========
class Scheduler {
    std::queue<Task> tasks;

public:
    void schedule(Task task) { tasks.push(std::move(task)); }

    void run() {
        while (!tasks.empty()) {
            auto task = std::move(tasks.front());
            tasks.pop();
            task.resume();
            if (!task.done()) {
                tasks.push(std::move(task));  // 未结束则重新入队
            }
        }
    }
};

// ========== 3. 模拟异步操作的 Awaiter ==========
struct AsyncSleep {
    int duration;
    bool await_ready() const noexcept { return false; }  // 总是挂起

    void await_suspend(std::coroutine_handle<> h) const noexcept {
        std::thread([h, d = duration]() {
            std::this_thread::sleep_for(std::chrono::seconds(d));
            h.resume();
        }).detach();
    }

    void await_resume() const noexcept {}
};

// ========== 4. 业务协程：同步写法，异步执行 ==========
Task async_task(Scheduler& sched, int id) {
    std::cout << "Task " << id << " starting...\n";
    co_await AsyncSleep{1};  // 挂起 1 秒，不阻塞调度器
    std::cout << "Task " << id << " step 1 done\n";
    co_await AsyncSleep{1};
    std::cout << "Task " << id << " step 2 done\n";
}

int main() {
    Scheduler sched;
    sched.schedule(async_task(sched, 1));
    sched.schedule(async_task(sched, 2));
    sched.schedule(async_task(sched, 3));
    sched.run();
    return 0;
}

输出（三个任务交替执行） ：

arduino 复制代码

Task 1 starting...
Task 2 starting...
Task 3 starting...
Task 1 step 1 done
Task 2 step 1 done
Task 3 step 1 done
Task 1 step 2 done
Task 2 step 2 done
Task 3 step 2 done

这就是协作式调度的精髓：每个协程主动让出 CPU，调度器轮流唤醒。没有内核态切换，没有锁竞争，代码却像同步一样清晰。

四、让协程能循环：FinalAwaiter 技巧

上面的调度器有个问题------协程执行完就销毁了，无法实现"任务循环"或"多阶段执行"。解决方案是在 final_suspend 中返回自定义 Awaiter，将协程重新注册回调度器：

arduino 复制代码

cpp
struct FinalAwaiter {
    bool await_ready() const noexcept { return false; }

    void await_suspend(std::coroutine_handle<> h) const noexcept {
        // h 指向 Task，重新入队
        // scheduler_instance.schedule(Task{h});
    }

    void await_resume() noexcept {}
};

std::suspend_never final_suspend() noexcept {
    return {};  // 改为返回 FinalAwaiter 即可实现循环
}

这正是工业级协程框架（如 libco、cppcoro）的核心思路。

五、协程调度器 vs 线程池：性能正面刚

以下数据综合自多个工业实测与基准测试（GCC 11.2 + Linux 5.4 内核环境）：

指标	传统线程池	协程调度器	差距
单任务内存占用	~1MB（线程栈）	~几十 KB（协程帧）	约 30 倍
上下文切换开销	110 μs（内核态）	~几十 ns（用户态）	约 100 倍
10 万并发连接内存	>100 GB（不可行）	~几 GB（轻松）	天壤之别
10 万连接吞吐量	~5000 req/s	~6500 req/s（阿里云实测）	+30%
平均响应延迟	~50 ms	~40 ms	-20%
锁竞争	高（需互斥量/原子操作）	极低（单线程事件循环）	质的区别

阿里云函数计算服务的改造是最有力的实证：引入协程池后，吞吐量从 5000 提升至 6500 请求/秒，延迟从 50ms 降至 40ms。改造的核心就是用协程替代了"一线程一连接"的传统模型。

六、内存优化：协程帧的碎片化治理

协程帧在堆上分配，默认由 malloc 管理。高并发下碎片化是隐形杀手：

策略	碎片率	分配时间
默认 malloc	~20%	~0.5 μs/次
内存池（预分配 1024 字节块）	~5%	~0.1 μs/次

通过重载 promise_type 中的 operator new，将分配引导至内存池，可以将碎片率从 20% 压到 5%，分配速度提升 5 倍。

七、实战建议：什么时候用协程，什么时候用线程

场景	推荐方案	理由
CPU 密集计算（图像处理、矩阵运算）	线程池	需要真正并行，协程无法利用多核
高并发 I/O（Web 服务器、数据库连接池）	协程 + 少量线程	挂起不阻塞，单线程可承载数万协程
游戏服务器（逻辑 + 网络混合）	线程池处理逻辑 + 协程处理 I/O	混合场景的最优解
实时音视频编码	线程池 + OpenMP	必须多核并行

核心判断标准：任务是 I/O 密集还是 CPU 密集？ I/O 密集选协程，CPU 密集选线程。协程补充而非替代线程------用 8 个线程承载数万协程，才是高性能服务器的终极形态。

八、结语

C++20 协程的门槛确实不低，但回报同样惊人。它不是银弹，却是 I/O 密集型高并发场景下最锋利的那把刀。

从手写一个几十行的调度器开始，到理解 promise_type、awaiter、coroutine_handle 三位一体的协作机制，再到在生产环境中用协程池替换线程池------这条路，值得每一个 C++ 开发者走一遍。

2026 年了，别再用回调地狱折磨自己了。用同步的写法，写异步的逻辑，这才是 C++20 协程给你的真正自由。