用户级线程(ULT)在栈层面的工作机制与实现原理是怎样的？

核心结论 #

用户级线程的所有线程同样拥有独立的栈空间，但这套栈的管理、切换逻辑完全由用户态的线程库实现，内核全程无感知，和内核级线程（KLT）由内核维护PCB、页表映射的机制有本质区别。

和KLT栈机制的差异 #

先明确KLT的栈逻辑：每个KLT都有独立的用户栈和内核栈，对应内核里独立的PCB，页表中会单独标记每个栈的内存映射、访问权限，线程切换时由内核负责保存恢复栈指针、寄存器上下文，调度全在内核态完成。
ULT的运行逻辑完全不同：同一个进程下的所有ULT，本质上是共享同一个内核级线程的——也就是对应同一个内核PCB、共享同一套进程页表，内核根本不知道进程内部创建了多少个ULT，自然不会为每个ULT单独维护栈相关的元数据。

ULT独立栈的具体实现 #

整套机制没有内核参与，全部由用户态线程库完成，核心流程如下：

• 线程库初始化、或者创建新ULT时，会在当前进程的用户地址空间中，划出一块块大小固定（通常是2~8MB不等）的虚拟内存区域作为每个ULT的专属栈，这些区域都属于同一个进程的地址空间，全部在现有页表的映射范围内。
• 每个ULT会对应一个用户态维护的线程控制块（TCB，结构类似内核的PCB，但存储在用户态内存中），TCB里专门保存对应ULT的栈指针、栈基址、栈边界，以及其他通用寄存器的上下文快照。
• ULT发生调度切换时（比如调用线程库的yield主动让出CPU、或者被用户态调度器抢占），全程在用户态完成上下文保存恢复：线程库先把当前CPU的寄存器值、栈指针写入正在运行的ULT的TCB，再把下一个待运行ULT的TCB中保存的栈指针、寄存器值恢复到CPU寄存器上，直接跳转到该线程上次暂停的代码位置继续执行，整个过程不需要进入内核态，切换开销远低于KLT。
• 因为所有ULT的栈都在同一个进程地址空间内，ULT切换时完全不需要触发页表切换，页表早就把这些栈区域标记为用户态可读写，内核不会介入这个过程。

常见实现细节 #

• 大部分线程库不会在创建ULT时就给栈分配物理内存，只是先预留对应的虚拟地址空间，等线程实际运行、压栈触发缺页异常时，内核再按常规缺页处理逻辑分配物理页，这个过程对线程和线程库都是透明的。
• 为了避免单个ULT栈溢出踩坏相邻线程的栈数据，每个ULT的栈区域之间会设置一个无读写权限的守护页（guard page），一旦栈溢出触碰到这个页，就会触发段错误，这个机制和KLT栈的守护页类似，但页表权限的修改是线程库创建栈时主动调用系统调用完成的，不是内核为ULT主动配置的。
• 由于所有ULT共享同一个KLT，一旦其中一个ULT发起阻塞式系统调用（比如磁盘IO、sleep），内核会把对应的整个KLT设为阻塞状态，绑定在这个KLT上的所有ULT都会暂时无法运行，这是ULT模型的典型特性，和栈机制本身无关，但经常和ULT上下文切换逻辑被放在一起讨论。

内容的提问来源于stack exchange，提问作者user2277550