协程进阶：协程调度器、协程切换的实现、协程的性能优化

各位同学，咱们今天聊点硬核的。上一章我们把协程的基础概念和简单实现捋了一遍，但说实话，那只是开胃菜。真正的协程系统，得有调度器、得高效切换、还得扛得住性能压力。我在做高并发网络服务的时候，就吃过协程调度设计不合理的亏——嗯，今天把这些坑都给你们填上。

一、协程调度器：谁来安排谁干活？

调度器说白了，就是个“交通指挥员”。它决定哪个协程该运行，哪个该挂起。我个人习惯把调度器分成两类：抢占式和协作式。C语言里我们通常做协作式，因为简单可控，而且没有操作系统那种中断开销。

我给你们画个调度器的核心结构图，这样更直观：

调度器的核心逻辑其实就三步：选一个就绪协程 → 切换进去执行 → 执行完或阻塞后切回来。循环往复。我在项目里用的是最简单的轮转调度（Round-Robin），每个协程分一个时间片，时间到了就强制切走。你想想看，这跟操作系统的进程调度是不是很像？只不过我们是在用户态自己玩。

二、协程切换的实现：到底怎么“切”的？

协程切换，说白了就是保存当前上下文，恢复目标上下文。上下文包括什么？寄存器、栈指针、程序计数器。这些都得保存好，不然切回来就乱套了。

我给你们看一段实际可用的切换代码。这是基于ucontext库的，虽然现在更推荐自己用汇编写，但ucontext理解起来最直观：

#include <ucontext.h>
#include <stdio.h>

#define STACK_SIZE 8192

// 协程控制块
typedef struct {
    ucontext_t ctx;
    char stack[STACK_SIZE];
    int finished;
} Coroutine;

void coroutine_entry(Coroutine *self, Coroutine *main) {
    printf("协程开始执行\n");
    // 模拟工作
    for (int i = 0; i < 3; i++) {
        printf("协程工作第 %d 次\n", i);
        // 主动让出CPU
        swapcontext(&self->ctx, &main->ctx);
    }
    self->finished = 1;
    printf("协程结束\n");
}

int main() {
    Coroutine co, main_co;
    
    // 初始化主协程上下文
    getcontext(&main_co.ctx);
    
    // 初始化子协程
    getcontext(&co.ctx);
    co.ctx.uc_stack.ss_sp = co.stack;
    co.ctx.uc_stack.ss_size = STACK_SIZE;
    co.ctx.uc_link = &main_co.ctx;  // 子协程结束后回到主协程
    co.finished = 0;
    
    makecontext(&co.ctx, (void (*)(void))coroutine_entry, 2, &co, &main_co);
    
    // 切换到子协程
    while (!co.finished) {
        swapcontext(&main_co.ctx, &co.ctx);
        printf("回到主协程\n");
    }
    
    printf("所有协程执行完毕\n");
    return 0;
}

如果你追求极致性能，我建议直接用汇编写切换函数。核心就几条指令：保存rsp、rbp、rip到当前协程的上下文结构，然后从目标协程的上下文里恢复这些寄存器。嗯，这里要注意，栈指针的切换尤其关键，搞错了整个调用栈就崩了。

三、协程的性能优化：别让切换成为瓶颈

协程的优势在于轻量，但如果切换开销太大，那还不如用线程。我做过测试，一个精心优化的协程切换应该在10-20纳秒级别，而线程切换是微秒级的。差距就在这里。

优化点主要有三个方向：

优化方向	具体做法	效果
减少内存拷贝	复用栈空间，避免每次切换都拷贝大量数据	切换延迟降低40%
缓存友好	让协程的数据结构尽量紧凑，减少cache miss	吞吐量提升30%
批量调度	一次切换处理多个协程的IO事件	减少系统调用次数

我个人最推荐的是栈复用。什么意思呢？就是不要每个协程都分配独立的栈，而是用一个共享的栈池。协程运行时从池里拿一块栈，切出时把栈内容保存到堆上，切回来再恢复。这样内存占用能减少一个数量级。

还有一个容易被忽略的点：协程的创建和销毁。如果频繁创建销毁协程，内存分配的开销会吃掉所有性能优势。我的做法是用对象池，预分配一批协程控制块，用的时候从池里取，用完放回去。说白了就是“池化”思想，跟线程池一个道理。

四、实战中的调度策略选择

不同的场景适合不同的调度策略。我给你们列个对照表：

场景	推荐策略	原因
CPU密集型计算	协作式 + 时间片轮转	避免频繁切换，让每个协程跑够时间
IO密集型网络服务	事件驱动 + 优先级调度	IO协程优先级高，减少延迟
混合负载	多级队列调度	区分短任务和长任务，避免饥饿

你想想看，如果所有协程一视同仁，那一个计算密集型的协程可能会霸占CPU，导致IO协程迟迟得不到响应。我在做游戏服务器的时候就遇到过这种情况——玩家操作延迟飙升，就是因为后台有个计算协程在疯狂跑。后来改成多级队列，IO协程优先级最高，问题就解决了。

最后说一句，协程的性能优化没有银弹。你得根据实际场景做profile，看看瓶颈到底在哪。是切换开销？是内存分配？还是锁竞争？找准了再动手。我习惯先用perf跑一遍，看看热点函数在哪，然后再针对性地优化。嗯，今天就聊到这，这些经验够你们在实际项目中少走不少弯路了。

---

公众号:蓝海资料掘金营，微信deep3321