小狐狸与小道士MIT6.S081这门课，前面几篇学习记录我陆续写了系统调用、页表、陷阱那一套东西。本来以为扛过lab 5的lazy allocation就已经算入门了，结果到了Lab 7：Multithreading，我才发现前面那些都是热身。这一篇从一个很朴素的问题开始：操作系统里到处都在说进程、线程，它们到底是怎么“切”来切去的？在这个lab里，我不光要搞懂xv6内核线程切换的真相，还得亲手在用户态写一个线程切换机制，再面对一把锁引发的性能危机。
这篇记录面向正在啃MIT6.S081、或者对操作系统线程、并发机制感兴趣的朋友。看完你能收获三件事：xv6中进程切换的完整路径、用户态线程（Uthread实验）的具体实现套路，以及锁竞争优化（内存分配器、buffer cache）的实战思路。这些东西放到任何一门语言的多线程编程里，底层原理都是相通的。
1. 这次实验在干什么：xv6里的线程究竟长什么样
1.1 先复习一下xv6的进程模型
xv6是个教学操作系统，它的进程模型非常“朴素”：每个进程只有一个线程。也就是说，一个进程 = 一份地址空间 + 一条执行流。这个设计让进程切换变得相对简单：切换进程的时候，既要把寄存器状态、栈指针这些执行上下文保存好，还得把页表切掉，因为每个进程的地址空间是独立的。
我前面做系统调用lab时写过fork、exec，那时对进程的理解还停留在“它是资源分配的单位”。到了多线程这块，视角得换成“它是调度的单位”——CPU在某一时刻只能跑一条执行流，多进程之间的“同时运行”全靠快速切换模拟出来。xv6把这种切换点做得特别规矩：定时器中断一来，当前进程就被迫让出CPU，进入内核态走一遍调度流程，选下一个RUNNABLE状态的进程继续跑。我画过一条特别直观的路径：用户态 -> trap到内核 -> yield -> sched -> swtch -> scheduler -> swtch到下一个进程。这条链路在整个lab里被反复引用，后面所有代码分析都围绕它展开。
1.2 多线程要解决的两个核心问题：上下文切换与同步
接触过多线程编程的人都知道，线程之间的核心矛盾就两个：一是CPU怎么在多个执行流之间切换而不乱套，二是多个执行流同时访问共享数据时怎么保证不出错。xv6这个lab就是围绕着这两个矛盾设计的。
第一个问题对应“切换机制”，课程给出的答案是swtch函数和context结构体。说白了就是：每次让出CPU之前，把当前这条执行流用到的寄存器全部存到内存里；下次轮到自己执行时，再把寄存器恢复回去。这件事听着简单，实际上一堆细节，比如哪些寄存器要存、哪些不用存，为什么调度器自己也有一个context，都是需要脑子的地方。
第二个问题对应“同步机制”，课程给出的答案是自旋锁spinlock。锁存在的意义是保证临界区互斥：同一时刻只有一个CPU能进入临界区。不过锁一旦用不好，就会变成性能杀手。实验里那两个优化题（内存分配器、buffer cache）正是拿真实场景告诉我们：锁粒度太大，多核CPU会大量时间花在等锁上，整个系统性能不升反降。
1.3 为什么用户态线程也要做一遍切换
Lab 7里第一个任务看起来有点“返璞归真”：不用管硬件中断，不用管页表切换，只是在用户态实现一个简单的线程调度器。刚开始我觉得这是不是有点多余，毕竟内核里已经有了一套线程切换机制。
做完才发现，这个任务的教学价值非常高。用户态线程切换和内核线程切换，本质上是同一件事：都需要保存和恢复寄存器、都需要一个调度队列、都需要给每个线程分配自己的栈。差别在于用户态线程共享同一个地址空间，所以不需要切换页表，也不需要陷入内核，切换开销小得多。但缺点也很明显：一个用户态线程阻塞在系统调用上，整个进程的所有线程都得跟着停。这种权衡，如果不在代码里亲手调一遍，光靠看书根本体会不到。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 切换机制拆解：swtch、scheduler与context
2.1 context要保存哪些寄存器，为什么是“这些”
先看xv6内核里context结构体的定义：
c复制// kernel/proc.h
struct context {
uint64 ra;
uint64 sp;
uint64 s0;
uint64 s1;
uint64 s2;
uint64 s3;
uint64 s4;
uint64 s5;
uint64 s6;
uint64 s7;
uint64 s8;
uint64 s9;
uint64 s10;
uint64 s11;
};
一共14个寄存器：ra（返回地址）、sp（栈指针）、s0到s11（callee-saved寄存器）。为什么只需要保存这些？这是RISC-V调用约定决定的。RISC-V里把寄存器分成两类：caller-saved和callee-saved。caller-saved寄存器（比如t0-t6、a0-a7）由调用者自己负责保存，如果一个函数要用这些寄存器，它得自己找地方存好，所以跨函数切换的时候不需要管它们。callee-saved寄存器则相反，如果调用者希望这些寄存器的值在函数调用之后还能留下来，需要被调用者帮忙保存。
swtch本质上是一个特殊的“函数调用”：我们从一个执行流跳到另一个执行流，相当于让被切出的线程“暂时冻结”，让被切入的线程从上次冻结的地方继续跑。为了保证冻结现场完整，只需要保存那些“被调用者负责保护”的寄存器就行。我一开始疑惑过为什么不像trap那样把所有寄存器都存一遍，后来想明白了：trap保存现场是给用户态程序看的，需要完整的通用寄存器；而swtch只在内核态执行流之间跳转，s0-s11加ra加sp已经足够维持一个函数调用的栈帧链了。
2.2 一次完整进程切换的七个步骤
xv6的进程切换不是“进程A直接切到进程B”，而是必须经过调度器中转。原因是调度器掌握所有进程的状态，它来决定下一步跑谁。我梳理一下我debug时反复对照的完整流程：
第一步，CPU收到定时器中断，进入内核态，保存用户态寄存器到当前进程的trapframe。
第二步，trap handler发现是定时器中断，调用yield()，进程主动让出CPU。
第三步，yield()里给进程加锁，把state改成RUNNABLE，然后调sched()。
第四步，sched()做一系列检查（比如当前进程必须是RUNNING、中断必须已经关闭），然后调swtch(&p->context, &c->context)，把当前进程的执行现场存入p->context，同时装载当前CPU调度器c->context的现场。
第五步，CPU现在跑的是scheduler()函数里swtch调用的下一行代码。调度器继续循环，找下一个RUNNABLE进程。
第六步，找到后，把新进程state改成RUNNING，执行swtch(&c->context, &p->context)，调度器现场存入c->context，装载新进程的context。
第七步，新进程从它上一次被切出的那一行（也就是sched()里的swtch调用返回处）继续执行，一路返回到yield()，最后trap返回用户态。
第七步里藏着一个精妙之处：新进程“醒来”之后并不在scheduler的循环里，而是回到自己上次的yield调用处。每一个进程都以为自己是主动让出CPU的，完全不知道中间隔了一个调度器。这一点看懂之后，我对操作系统的整体设计瞬间有了不一样的感知。
2.3 用户态线程实验（Uthread）怎么照着抄
做Uthread实验的时候，官方给的模板里已经有了thread_create和thread_schedule的骨架，我的任务是补全thread_switch的汇编实现，并且在thread_create里把新线程的初始context设置好。这活儿的核心逻辑几乎就是照搬内核的swtch。
我参考内核的swtch.S写了用户态版本：
asm复制# user/uthread_switch.S
.text
.globl thread_switch
thread_switch:
sd ra, 0(a0)
sd sp, 8(a0)
sd s0, 16(a0)
sd s1, 24(a0)
sd s2, 32(a0)
sd s3, 40(a0)
sd s4, 48(a0)
sd s5, 56(a0)
sd s6, 64(a0)
sd s7, 72(a0)
sd s8, 80(a0)
sd s9, 88(a0)
sd s10, 96(a0)
sd s11, 104(a0)
ld ra, 0(a1)
ld sp, 8(a1)
ld s0, 16(a1)
ld s1, 24(a1)
ld s2, 32(a1)
ld s3, 40(a1)
ld s4, 48(a1)
ld s5, 56(a1)
ld s6, 64(a1)
ld s7, 72(a1)
ld s8, 80(a1)
ld s9, 88(a1)
ld s10, 96(a1)
ld s11, 104(a1)
ret
关键点在于创建线程时怎么初始化context。先给线程分配一块栈空间，然后把context中的sp指向栈顶，把ra指向线程要执行的函数地址。这里有个坑：按照调用约定，a0到a7是caller-saved寄存器，不是context保存的范围，所以如果想让线程函数接收参数，必须在创建线程之前就把参数放进栈里或者想办法传给thread_wrapper。xv6课程里线程函数都无参数，这个坑没有明说，但自己设计线程库时绕不开。
c复制void
thread_create(void (*func)())
{
struct thread *t;
for (t = all_thread; t < all_thread + MAX_THREAD; t++) {
if (t->state == FREE) break;
}
t->state = RUNNABLE;
t->context.ra = (uint64)func;
t->context.sp = (uint64)t->stack + STACK_SIZE;
}
2.4 花絮：xv6里的抢占式调度
xv6在每个CPU上开了定时器中断，这样即使进程自己不主动让出CPU，也会被定时器打断，强制进入调度流程。这个过程叫抢占式调度，好处是对交互型任务更公平，不会出现一个死循环进程把整个系统卡死的局面。
我在跟踪代码时发现，xv6在启动时通过timerinit给每个CPU设置了定时器，每次中断后设备会自动重新加载，所以能稳定地周期性触发。这个机制是后面几个调度实验（比如MLFQ调度器）的基础，Lab 7虽然没有要求改调度算法，但理解抢占式调度对理解线程切换必不可少。
3. 锁的正确打开方式：从spinlock到原子操作
3.1 自旋锁结构体与acquire/release
xv6的自旋锁定义在kernel/spinlock.h和kernel/spinlock.c里。结构体就三个字段：locked标记、name调试信息和持有该锁的CPU编号。别看它简单，acquire和release的实现细节非常讲究：
c复制void
acquire(struct spinlock *lk)
{
push_off();
if(holding(lk))
panic("acquire");
while(__sync_lock_test_and_set(&lk->locked, 1) != 0)
;
__sync_synchronize();
lk->cpu = mycpu();
}
__sync_lock_test_and_set是GCC内建的原子交换操作，在RISC-V上会翻译成amoswap指令。这条指令能保证“读取旧值+写入新值”是原子的，多个CPU同时执行也不会有并发问题。如果locked从0变成1成功，说明锁拿到手了；如果locked本来就是1，就说明别人持有锁，当前CPU只能死等。
release的逻辑正好相反：先清掉cpu字段，执行内存屏障，再把locked置0。注意释放锁用的是__sync_lock_release，在RISC-V上通常对应amoswap或者简单的store指令配合内存屏障。之所以还是用原子操作，是为了防止编译器或者CPU对指令重排，保证“临界区的操作一定在释放锁之前完成”。
3.2 一个必踩的坑：为什么acquire必须先关中断再拿锁
我刚看acquire代码时有个很大的疑问：为什么acquire进来第一件事是push_off()关中断，而不是先去做原子交换？后来自己想象了一个死锁场景，一下子就想通了。
假设CPU0上的进程A持有了锁L，正在临界区里跑。此时来了一个中断，CPU0跳转到中断处理程序。这个中断处理程序如果也想获取锁L，就会在自旋锁的while循环里死等，因为锁L的持有者是进程A，而进程A已经被中断打断，只有中断处理程序返回后才有机会释放锁。这就成了单核上的死锁：抢占者等着被抢占者释放锁，但被抢占者永远没机会执行。
关中断能从根源上防止这个问题，相当于告诉CPU“我现在正在临界区，你不要再拿中断来打断我了”。但为什么用push_off而不是直接关中断？因为可能出现嵌套获取锁的情况——一个CPU已经因为外层锁关了中断，内层锁的acquire如果直接开中断，就会破坏外层锁的保障。push_off会维护一个嵌套计数，保证最外层释放锁时才真正恢复中断。
3.3 RISC-V原子指令与内存屏障
在RISC-V上，除了amoswap，还有lr/sc（Load-Reserved/Store-Conditional）这类原子指令。xv6只用amoswap就够实现锁了，但理解lr/sc机制也很重要，因为很多更复杂的无锁数据结构会用它们来实现read-modify-write。
内存屏障这块我单独说一句。acquire里的__sync_synchronize()在RISC-V上生成fence指令，作用是把fence之前的内存操作在fence之后的操作之前对其他CPU可见。没有这个屏障，即使拿到了锁，也可能读到别的CPU尚未写完的共享数据。拿锁本身是原子操作，但原子操作不保证内存顺序，这俩容易混淆。我调试的时候曾经只盯着原子性，忽略了内存序问题，结果在某个优化版本上测出过数据不一致，后来加了fence才稳定。
3.4 实验二：给内存分配器“去锁”
Lab 7的第二个任务里有一个非常经典的性能问题：xv6的内存分配器维护着一个全局freelist和一个全局锁kmem.lock。所有CPU分配内存时都要抢这把锁。多核场景下，锁竞争非常严重，因为内存分配是高频操作，频繁分配和释放的进程几乎全程在等锁。
优化思路也直接：每个CPU维护一个独立的freelist，配一把自己CPU的锁。这样大部分分配和释放都不需要跨CPU抢锁，只有自己的freelist空了，才去别人的freelist“借”一些内存页。我做的per-CPU实现大概是这样：
c复制struct {
struct spinlock lock;
struct run *freelist;
} kmem[NCPU];
void
kfree(void *pa)
{
struct run *r;
int cpu;
if(((uint64)pa % PGSIZE) != 0 || (char*)pa < end || (uint64)pa >= PHYSTOP)
panic("kfree");
acquire(&kmem[cpu].lock);
r = (struct run*)pa;
r->next = kmem[cpu].freelist;
kmem[cpu].freelist = r;
release(&kmem[cpu].lock);
}
这里有个小细节：kfree里要调cpuid()获取当前CPU编号。xv6没多核抢占问题，因为内核线程在某个CPU上不会被迁移走，所以cpuid()的结果在函数执行期间是稳定的。如果放到别的系统上，就得关抢占再获取CPU编号，不然可能切到另一个CPU上去，锁就上错了。
4. 实验实操记录：Uthread、Allocator和Bcache的完整实现
4.1 Uthread：补全thread_create与thread_switch
这一节我记录一下完整的实验操作过程，方便复现。先切到uthread目录，lab模板里已经给了uthread.c和uthread_switch.S。我的第一步是改uthread_switch.S，把寄存器保存和恢复的代码写好。然后是修改thread_create函数，给新线程的context设置ra和sp。
测试程序里每个线程做的事情是循环打印自己的名字，然后让出CPU。一开始我只写了thread_switch，没有正确初始化ra，跑起来立刻panic。后来仔细对照内核里的allocproc函数，发现xv6在创建进程时会把context.ra设成forkret，而forkret的作用就是“从内核态返回用户态”。在用户态线程这里，context.ra直接设成线程函数地址就行，因为切换回来时swtch会ret到ra，相当于直接调用线程函数。
我还顺手验证了一下：如果给thread_create增加一个参数传递机制会怎样？最简单的办法是在线程栈里预先把参数压进去，然后在thread_switch的ret之后用一个wrapper函数取出参数再调用真正的线程函数。这和内核里创建内核线程时用wrapper传参的思路一致。
4.2 内存分配器锁优化：给每个CPU一个自己的freelist
这个实验的测试方法很直观：跑kalloctest，看看锁竞争次数从多少降到多少。我一开始偷了个懒，直接把全局freelist换成per-CPU freelist，但kfree时还是只会释放到当前CPU的列表里。这样会导致一个问题：如果CPU0一直分配、CPU1一直释放，CPU0的freelist很快就空了，不停去CPU1那边借页，锁竞争依然严重。
所以“借页”这个动作是必须的。我在kalloc里的实现是：先试自己CPU的freelist，没有的话就遍历所有CPU的freelist，找到有剩余页的那个CPU，把整条freelist拿走一半左右。这个思路和Linux内核的per-CPU页分配器有点像，区别是我这里实现要粗糙得多。把整条链表搬走有个好处：只需要操作对方CPU的锁，不需要持有多把锁，避免死锁。
跑了kalloctest之后，锁竞争次数从原来的一两百万量级直接降到了个位数。当然代价也很明显：内存页在CPU之间分配不均。测试能过，但如果能再做一个空闲页统一回收机制就更完善了。
4.3 Buffer cache：哈希分桶减竞争
如果说allocator实验是热身，那buffer cache实验就是正餐。xv6的block cache原来是一张全局链表加一把大锁bcache.lock，所有对缓存块的查找、引用、LRU淘汰都在同一把锁下进行。多核访问不同块时也要互相等待，竞争非常夸张。
我的实现方案是哈希分桶：维护一个固定大小的哈希表，每个桶是一个双向链表，配一把独立的锁。根据block number做哈希，快速定位到目标桶，然后在桶内查找目标buffer。如果找不到，就在当前桶里找refcnt==0的buffer做LRU替换。
这里值得记录的是两个实现取舍。第一个，哈希表初始化的时机：我在binit里把所有NBUF个buffer按编号初始化并挂到哈希桶中。因为NBUF是固定的，哈希表大小也是固定的，所以每个buffer只属于一个桶。第二个，跨桶LRU的问题：官方测试的随机负载下，一个桶里总能找到可替换的空闲buffer，所以只在桶内做LRU就能通过。我一开始想做一个全局LRU，结果发现要么需要持有多把锁，要么需要在桶之间搬移节点，复杂度瞬间上升。后来参考网上一些实现，确定只在桶内做LRU足够满足课程测试。
测bcache的脚本会跑一堆并发读写，然后报告锁竞争次数。优化后的结果对比很感人：全局锁版本几乎每一个块操作都在等待，分桶版本只有在哈希冲突时才有竞争。这个实验让我彻底理解了“锁粒度”这个东西对系统性能的影响有多夸张。
4.4 测试验证与性能对比
课程给的测试脚本是make grade，它会分别跑uthread、kalloctest、bcachetest以及原有课程的其他测试。我挨个跑完，确认没有回归问题。uthread的测试会看两个线程是否交替打印输出，kalloctest看锁竞争次数是否下降，bcachetest也是类似逻辑。
我额外记录了一下三个任务完成前后的时间对比。其实最直观的还是kalloctest输出的锁统计：未优化前，系统启动后内存分配相关锁的竞争次数可以轻松到几十万次以上；优化后基本只剩初始化阶段的几次竞争。bcachetest的表现也类似，分桶锁对冲随机读写负载的效果立竿见影。
做这些优化的过程中，我反复使用的一个工具是xv6自带的backtrace，它可以打印内核栈调用链。配合panic信息几乎能定位大部分死锁和空指针问题。
5. 常见问题与排查技巧实录
5.1 用户态线程栈溢出：一个静悄悄的灾难
uthread的每个线程默认栈大小是STACK_SIZE，在模板里定义成了8192字节（8KB）。如果你的线程函数里有个稍微大一点的局部数组，直接就把栈顶给踩穿了。关键是用户态线程没有内核线程那样的guard page，栈溢出不会立刻panic，而是可能悄悄破坏相邻线程的栈数据，最后出现极其诡异的打印结果。
排查这种问题的方法很原始：在thread_switch里加打印，或者在每个线程栈的底部填充一个magic number，定期检查是否被覆盖。我当时用一个全局数组填充了0xdeadbeef，线程调度几十次后发现有线程的栈底被改写了，这才确认是栈溢出。所以做这类实验，栈大小宁多勿少。
5.2 第一次调度就crash：ra哪里去了
有一种经典的crash发生在创建完所有线程第一次调用thread_schedule的时候。现象是ret之后跳到了一个非法地址，然后panic。原因大多是thread_create里没有设置context.ra，或者context.sp设置错了。
我复盘了一下自己的错误：我一开始把sp指向了栈的起始地址，也就是t->stack，而不是t->stack + STACK_SIZE。RISC-V的栈是向下增长的，所以初始sp必须指向栈最高地址，否则函数第一条指令push返回地址时就直接踩到栈外面了。这个方向和x86一致，但跟我平时写ARM时的习惯刚好相反，值得注意。
5.3 死锁排查：两把锁互相等待
做buffer cache实验时，我第一次尝试让buffer能够在桶之间移动，结果陷入了一个经典死锁：CPU0持有了桶A的锁，想去拿桶B的锁；CPU1持有了桶B的锁，想来拿桶A的锁。两边都在自旋等待对方释放，系统直接卡死。
死锁出现时，xv6的panic信息帮不上太多忙，因为连panic都执行不了。我的排查思路是先在acquire的while循环里加一个打印，看哪两个CPU同时卡在某两把锁上。后来网上搜了一下，一个更专业的做法是给每把锁记录持有者CPU和等待者，做成锁依赖图。不过对这个课程实验来说，最省事的方法还是避免同时持有两把锁：要么全局的大锁，要么只在当前桶内分配buffer、绝不跨桶移动。
5.4 从xv6到Java/C++/Python多线程：通用心智模型
做完Lab 7再回头看日常开发里的多线程，很多东西其实是相通的。比如Java里的synchronized、C++的std::mutex，本质上都是锁的抽象，底层要么是futex，要么是spinlock，跟xv6的spinlock同源。Python的多线程因为有GIL，锁竞争的方式略有不同，但同步的基本概念完全一致。
我特别想说的是“多线程面试题”里常问的线程状态切换。xv6里RUNNABLE、RUNNING、SLEEPING这套状态机，和Java里NEW、RUNNABLE、BLOCKED、WAITING、TIMED_WAITING、TERMINATED是一回事，只是粒度更细。理解了xv6内核怎么用一个context实现状态切换，再去背那些面试题，就能理解为什么Java线程在等待锁的时候会进入BLOCKED状态而不是继续占用CPU：因为操作系统会在锁等待时把线程挂起，让出CPU给其他线程。这套心智模型是通用的。
6. 写在最后的一点体会
这个lab做下来，我最直观的感受是：操作系统里的“多线程”不是一个抽象概念，而是由一条一条指令、一个又一个寄存器的保存与恢复组成的。以前写Java并发代码，我只关心锁的用法，这次亲手实现了用户态线程切换和内核锁优化，才对“上下文切换到底要保存什么”“自旋锁为什么是性能杀手”有了真正的体感。
如果你也在做MIT6.S081，我建议不要只满足于通过测试。uthread做完之后，可以自己试着加一个线程sleep和wakeup机制，就会发现用户态线程的协作调度和内核的sleep/wakeup殊途同归。性能优化实验做完之后，可以尝试统计不同哈希桶数量对bcache锁竞争的影响，这个动手过程比单纯看结论有意思得多。多线程这条路，入门靠语法，深入靠系统，而MIT6.S081正好给了你一个从系统层面理解它的绝佳机会。