linux ucontext 是一套用户级上下文切换API，通过保存和恢复CPU寄存器状态实现协程与轻量级任务调度，是理解现代异步编程的基石。
linux ucontext 究竟是什么？一套用户级上下文切换的底层API
从POSIX规范到Linux实现
ucontext（用户上下文）系列函数源于System V，后被POSIX.1-2001采纳，虽然POSIX.1-2008将其标记为废弃，但Linux glibc至今依然完整支持，这套API包含四个核心函数：getcontext、setcontext、makecontext、swapcontext，以及一个结构体ucontext_t，据GNU C Library手册，ucontext_t 保存了程序执行时的所有寄存器值、栈指针、信号掩码和链接上下文信息，相当于一次完整的CPU快照。
ucontext_t 结构体：寄存器、栈指针和信号掩码
ucontext_t 的定义通常包含以下关键成员：
- uc_link：指向下一个上下文，当当前上下文执行结束时会自动切换至此。
- uc_sigmask：信号掩码，决定哪些信号在上下文中被阻塞。
- uc_stack：为上下文分配的独立栈，由stack_t指定。
- uc_mcontext：机器相关上下文，保存通用寄存器、指令指针等。
这意味着,通过ucontext，我们可以在用户态完全控制一个执行流的挂起和恢复，而不需要陷入内核，这正是协程实现的基础。
linux ucontext 与 setjmp longjmp 对比：谁更适合任务切换？
非局部跳转 vs 完整上下文切换
setjmp/longjmp 提供的是非局部跳转，它保存的上下文仅限于栈指针、程序计数器以及部分寄存器，不保存信号掩码，也无法恢复完整的CPU状态，而ucontext保存了所有寄存器包括浮点寄存器，以及信号掩码，并可显式指定栈空间，setjmp适合在函数调用链中跳出异常，而ucontext适合需要完整切换执行流的场景，如协程调度。
使用场景差异：setjmp用于异常处理，ucontext用于协程
业内专家指出,在实现协作式多任务时，ucontext是比setjmp更自然的选择，一个简易协程库需要为每个协程分配独立栈，并在切换时保存当前上下文，切换到下一个，setjmp无法隔离栈，因为longjmp会跳回保存点，但栈上其他函数调用可能已被破坏，而ucontext的makecontext允许为每个上下文分配全新栈，从根本上避免了栈污染。
性能对比：ucontext开销更高但更灵活
ucontext每次切换需要保存和恢复上百个寄存器以及信号掩码,而setjmp/longjmp只保存少量寄存器，据APUE（Advanced Programming in the UNIX Environment）介绍，ucontext在早期实现中可能涉及系统调用，但现代glibc版本已将切换优化为纯用户态操作，虽然ucontext的切换开销比setjmp高一个数量级，但它提供的灵活性尤其是独立栈和信号掩码控制使其成为协程实现的首选。
linux ucontext 协程实现：从零搭建一个简易协程库
分配独立栈与初始化上下文
为每个协程分配一块内存作为栈,并创建ucontext_t对象，调用getcontext获取当前上下文，然后修改该上下文使其指向新栈和新入口函数。
ucontext_t ctx;
getcontext(&ctx);
ctx.uc_stack.ss_sp = malloc(SIGSTKSZ);
ctx.uc_stack.ss_size = SIGSTKSZ;
ctx.uc_link = NULL; // 或指向主上下文
makecontext(&ctx, (void ()(void))func, argc, args...);使用makecontext设置入口函数
makecontext 会修改uc_mcontext，将程序计数器设为入口函数，并设置栈指针和参数，注意，参数必须为整数类型，且只能传int类型，如果要传指针，需要借助联合体技巧，以下是一个包装宏的例子：
#define MAKE_CONTEXT(ctx, func, args...)
do {
getcontext(&ctx);
ctx.uc_stack.ss_sp = malloc(SIGSTKSZ);
ctx.uc_stack.ss_size = SIGSTKSZ;
makecontext(&ctx, (void ()(void))func, ##args);
} while(0)使用swapcontext实现协程切换
swapcontext(old, new) 保存当前上下文到old，然后恢复new的上下文，协程调度器只需维护一个协程队列，循环调用swapcontext即可，一个典型的调度循环如下：
while (current_ctx) {
ucontext_t next = pick_next_ready();
if (next) swapcontext(current_ctx, next);
}注意事项：栈溢出、信号处理与可移植性
- 栈大小：SIGSTKSZ通常足够，但若协程中有大量局部变量，需提前调整size。
- 信号：ucontext切换时信号掩码会一起保存，避免信号丢失，但需注意不要在多信号环境下频繁切换。
- 可移植性：ucontext在macOS、FreeBSD等系统上也被支持，但glibc自从2.26版本后，makecontext和swapcontext的实现有变化，需注意兼容性，尤其是在Linux上编译时需定义
_GNU_SOURCE。
linux ucontext 性能实测：上下文切换到底有多快？
与线程切换对比
线程切换需陷入内核,开销在微秒量级；而ucontext完全在用户态，据行业共识，一次swapcontext的耗时大约在50-200纳秒（视硬件和glibc版本），这意味着，在需要大量高频切换的场景（如网络服务器、游戏引擎）中，ucontext协程可以显著降低调度开销，在单线程中模拟数百个并发任务，ucontext的切换成本远低于线程切换。
现代优化：浮点寄存器和信号掩码的处理
早期ucontext实现会保存完整的浮点寄存器状态,带来额外开销，现代glibc针对x86_64做了优化，浮点状态仅在必要时保存，通过合理设置信号掩码，可以减少切换时系统调用的次数，开发者可以通过直接操作uc_mcontext中的浮点标志位来进一步控制，但需谨慎，因为这依赖具体架构。
linux ucontext 使用中的常见问题
问题1：ucontext 是否线程安全？
ucontext系列函数不是线程安全的,多个线程同时操作同一个上下文可能导致未定义行为，建议每个协程独享自己的ucontext_t，并在调度时加锁保护，如果一定要在线程间共享上下文，务必使用互斥锁。
问题2：makecontext 后能否修改栈？
不能,makecontext会记录栈指针，运行时栈内容由协程函数自身管理，若提前修改栈，会导致函数返回时崩溃，正确的做法是在入口函数中分配或使用栈变量，或者通过uc_stack的ss_flags标记栈属性。
问题3：ucontext 与信号处理的关系？
在信号处理函数中,不能调用getcontext、setcontext等，因为信号处理函数运行在中断栈上，上下文状态特殊，但可以通过设置信号掩码屏蔽某些信号来避免冲突，或者在信号处理函数中设置标志，待信号恢复后再进行上下文切换。
linux ucontext 作为用户态上下文切换的经典实现，虽然在现代编程中逐渐被makecontext/swapcontext的替代方案（如boost.context、libco）取代，但它的设计思想和底层机制依然是理解协程、异步编程的基础，掌握ucontext，能让你更深入地理解操作系统上下文切换的本质，并在实际开发中灵活选择更合适的工具。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/linux-ucontext%e6%98%af%e4%bb%80%e4%b9%88%ef%bc%8c%e6%80%8e%e4%b9%88%e7%94%a8%ef%bc%9f/
