线程的本质

做这一章的题，最容易踩的坑不是"不会"，而是"会得太多"或"会得太少"。
教材给你一套干净的二分法：进程是资源分配的基本单位，线程是 CPU 调度的基本单位。这套说法必须背，考场按它作答。
但真实的 Linux 里，根本没有"线程"这种内核对象——只有 task_struct，进程和线程只是共享程度不同的同一种东西。
这份笔记全程双轨：粉色 = 应试口径，青色 = 真实工程。冲突处会明确告诉你考场该写哪个。

要理解线程，最快的路径是理解 clone()。因为在 Linux 眼里，"创建进程"和"创建线程"是同一个动作，区别只在于——你告诉内核，新的执行流要和旧的共享多少东西。

1 · clone() 才是唯一的真相

clone(child_stack=0,
      flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
      child_tidptr=0x7fec70651a10)   // SIGCHLD：子进程死时通知父进程

const int clone_flags = (CLONE_VM      // 共享地址空间 ← 最本质的一条
                    | CLONE_FS      // 共享 cwd / root / umask
                    | CLONE_FILES   // 共享文件描述符表
                    | CLONE_SYSVSEM // 共享 SysV 信号量 undo
                    | CLONE_SIGHAND // 共享信号处理函数表
                    | CLONE_THREAD  // 加入同一 thread group ← POSIX「同一进程」
                    | CLONE_SETTLS  // 设置 TLS（fs base）
                    | CLONE_PARENT_SETTID
                    | CLONE_CHILD_CLEARTID | 0);

2 · tgid 与 pid：POSIX 语义是怎么拼出来的

单线程进程里 pid == tgid；多线程进程里主线程 pid == tgid，其余线程各有独立 pid 但 tgid 相同。getpid() 的内核实现返回的其实是 current->signal->pids[PIDTYPE_TGID]（历史上写作 group_leader->pid，2018 年由 Eric Biederman 引入 PIDTYPE_TGID 重构）。

3 · Windows NT：线程是真正的一等公民

创建流程（WinDbg 下打断点可见）：PspAllocateThread → PspCreateThread（设起始 RIP）→ PspInsertThread（链入进程线程链表）→ KeInitThread → KeStartThread（标记 READY 并插入调度器）→ KiStartUserThread。

4 · Solaris：M:N 曾经真的活过，然后死了

Solaris 9 之前的 T1 libthread 是历史上最著名的 M:N 实践：M 个用户线程复用在 N 个 LWP（轻量级进程） 上，映射关系是流动的——一个用户线程运行到一半都可能被换到另一个 LWP，而线程库对此无感知。

结果就是：priocntl() 只能改 LWP 的优先级，而用户线程与 LWP 的关系不稳定，于是你根本无法可靠地给某个用户线程设优先级。JVM 改了 LWP 优先级，线程转头就被挪到别的 LWP 上去了。

Solaris 9 起默认换成 T2 libthread，即"更简单、更健壮的 1:1 模型"。旧的 MxN 实现被体面地退役，连术语都废掉了——bound thread / unbound thread 的区分不复存在，因为每个用户线程都有专属 LWP。

"管理"这个词在教材里是 PCB 挂 TCB 的树形结构；在 Linux 里，它其实是一组引用计数。谁还在用这份地址空间、谁还在用这张文件表——数清楚了，管理就完成了。

1 · PCB / TCB：不存在的两个结构体

mm_struct 的双计数器：为什么要两个？

2 · 线程创建的完整路径

3 · pthread_join 的真相：一个 futex

4 · 线程组内的信号

退出也分两级：_exit() 只终止当前线程；exit_group() 终止整个线程组。C 库的 exit() 和 main 的 return 触发的都是后者——这就是"进程退出时所有线程一起死"的机制。

5 · 线程栈：不是常数，是 RLIMIT_STACK

• 主线程栈由内核动态增长；非主线程栈由 glibc 用 mmap 预先分配固定大小的匿名映射。
• 栈底带一个 guard page（PROT_NONE），触碰即 SIGSEGV，用于检测栈溢出。
• 8 MB 只是虚拟地址空间被预留，物理页惰性分配（缺页时才映射）。

这一节是本章的分数密集区。要记的不只是清单，更是"私有"这个词的两种含义——有些是硬件隔离的私有（不同进程的地址空间），有些只是约定上的私有（同进程线程的栈）。分不清这两者，第 32 题和第 33 题就会错。

1 · 完整清单

2 · 关键辨析：线程栈到底能不能互相访问？

3 · TLS：私有是怎么做出来的

编译器把 __thread 变量放进 .tdata（已初始化）和 .tbss（零初始化）节，链接器汇成 PT_TLS 程序头（type = 7）。x86-64 使用 Variant II 布局：

4 · 共享 fd 带来的并发陷阱

• offset 竞态：同进程线程共享同一个 open file description，也就共享 f_pos。man 手册明确指出：Linux 3.14 之前，共享同一 open file description 的两方并发 write()，更新文件偏移与写数据不是原子的，两方输出的数据块可能错误地重叠。3.14 修复。
• pread() / pwrite()：用调用者提供的 offset 原子完成"定位 + 读写"，且不改变 f_pos。man 原话大意：它们在多线程程序里特别有用，允许多个线程在同一 fd 上做 I/O 而不受其他线程改动偏移的影响。
• O_APPEND：每次 write() 前把偏移定位到文件末尾，定位与写作为单一原子步骤完成。（NFS 上不保证。）

这一节讲一个失败与复活的故事。M:N 模型在 1990–2000 年代被寄予厚望，然后在 Solaris、FreeBSD、Linux 上全线溃败；二十年后，它以 Go 的 goroutine、Java 的虚拟线程的形态彻底赢了。读懂这个反转，你就真正懂了用户级线程的优势和代价分别在哪。

1 · 三种模型

2 · 量化：切换到底差多少

为什么用户态切换能快 100 倍？因为它本质上就是一次普通函数调用。遵循 ABI 调用约定，caller-saved 寄存器已由编译器在调用点处理好，切换代码只需保存 / 恢复 callee-saved 寄存器 + 栈指针 + 返回地址。x86-64 上就是 rbx, rbp, r12–r15 加一个 rsp。

3 · M:N 的溃败：为什么两层调度器活不下去

4 · Scheduler Activations：最优雅的失败

核心思想：让内核与用户态线程库协作——内核向用户态发起 upcall（上调），机制类似 UNIX 信号，在一个已知入口地址激活用户态运行时。这个载体就叫 scheduler activation（SA）。

为什么它还是没被工业界采纳

• 实现复杂：内核与用户态双向大改。
• upcall 本身有开销：论文实测 upcall 延迟约为内核线程的 5 倍。
• 临界区恢复机制拖累常见路径：为了处理"线程在临界区被抢占"，论文用了复制临界区代码的办法，但即使临界区没有被抢占，每次自旋锁操作也要检查线程描述符。
• 最致命的：随着内核 1:1 线程被优化到足够快（futex、O(1) 调度器），性价比不再成立。

5 · 复活：现代运行时怎么绕开死结

历史 M:N 死于"两层调度器打架 + 阻塞 syscall 难处理"。现代语言运行时的破解方式是——不再和内核抢调度，而是把所有阻塞点都改造成让出点。

Go 的 G-M-P

Go 抢占的演进：从"永远卡住"到 SIGURG

Java 虚拟线程（Project Loom, JEP 444）

• JDK 19/20 预览（JEP 425 / 436），JDK 21（2023 LTS）正式（JEP 444）。
• continuation + carrier thread：虚拟线程的调用栈存在 Java 堆上（作为 continuation 对象），起始仅几 KB 并按需增长；执行时挂载（mount）到一个 carrier thread（来自 ForkJoinPool，默认大小 = 可用处理器数）。
• 阻塞即卸载（unmount）：阻塞 I/O 时 JVM 捕获 continuation（栈状态 + 局部变量）、把它从 carrier 卸载、栈存回堆，carrier 立刻去跑别的虚拟线程；I/O 完成后重新挂载到任一可用 carrier 恢复。
• JDK 的 java.net / java.nio / JDBC 等阻塞 I/O 已被改写为 park 虚拟线程而非阻塞 carrier——这是关键前提。
• pinning（钉住）：JDK 21–23 中持有 synchronized 监视器锁时无法卸载，Object.wait()、JNI/FFI 也会钉住。JDK 24 的 JEP 491 修复了 synchronized 导致的钉住。诊断参数：-Djdk.tracePinnedThreads=full。

Windows：Fiber 与 UMS

"线程切换比进程切换开销小"——这句话每个人都会背，但小在哪里才是考点。答案只有一句：同进程线程切换不换页表，所以不刷 TLB。其余的寄存器保存恢复，两者是一样的。

1 · 三个概念必须分清

2 · 同进程内核级线程切换：内核代码路径

ENTRY(__switch_to_asm)
    /* 保存 prev 的 callee-saved 寄存器 */
    pushq %rbp
    pushq %rbx
    pushq %r12
    pushq %r13
    pushq %r14
    pushq %r15

    /* 换栈：这两行就是"切换"的全部本质 */
    movq %rsp, TASK_threadsp(%rdi)   # rdi = prev，存旧 rsp
    movq TASK_threadsp(%rsi), %rsp   # rsi = next，载入新 rsp

    /* 栈保护 canary、RETPOLINE RSB 填充等 */

    /* 恢复 next 的 callee-saved 寄存器 */
    popq %r15
    popq %r14
    popq %r13
    popq %r12
    popq %rbx
    popq %rbp
    jmp __switch_to       # C 函数，处理 FPU / 调试寄存器等
END(__switch_to_asm)

3 · 跨进程切换：CR3、PCID 与 KPTI

• PCID（x86-64）/ ASID（ARM）：给 TLB 条目打上上下文标签，换 CR3 时不必全量刷 TLB。
• Linux 4.7 就引入了 PCID，但当时几乎没用武之地。Meltdown 改变了一切。
• KPTI（CVE-2017-5754 缓解）：用户态与内核态改用两套页表，每次进出内核都要写 CR3。若无 PCID，每次都全刷 TLB，开销灾难性。
• PCID 拯救了 KPTI：内核页表与用户页表各用不同 PCID 标签，两者可同时留在 TLB 里。代价是 KPTI 下每个 mm 需要两个 PCID，有效 ASID 空间减半到 2048。

4 · 用户级线程切换：换栈，仅此而已

swap64:
    ; 保存 callee-saved 寄存器到当前(old)栈
    push rdi
    push rbp
    push rbx
    push r12
    push r13
    push r14
    push r15

    mov  [rdi], rsp        ; *old = rsp   ← 保存旧栈指针
    mov  rsp, [rsi]        ; rsp  = *new  ← 载入新栈指针

    ; 从新(new)栈恢复
    pop  r15
    pop  r14
    pop  r13
    pop  r12
    pop  rbx
    pop  rbp
    pop  rdi
    ret                    ; 返回到新栈上的返回地址 = 新的 PC

补充：ucontext_t 结构较大（x86-64 Linux 上数百字节，因为还要存信号掩码，这需要一次系统调用），所以 Boost.Context 的 fcontext（纯汇编、不存信号掩码）比 ucontext 快约两个数量级。

5 · 隐性开销：真正贵的不是寄存器

6 · 时间片到底给谁：本章最大的教材陷阱

• 从状态角度看也说不通：多线程进程的线程可能同时分布在执行态、就绪态、阻塞态，不可能"所有内核级线程都处于执行态"。
• 版本时效性：Linux 长期用 CFS（2.6.23 引入），但自 Linux 6.6（2023）起默认调度器已换成 EEVDF。内核文档的措辞是"给每个 task 分配一个虚拟运行时"——再次印证调度实体是线程。

但请注意：这些是在"进程 / 组"粒度做 CPU 份额约束，底层被调度、被计时的仍然是单个 task。

7 · 缺页时的行为差异

点击任意一题展开完整解析。青底 = 正确表述，粉底 = 错误表述。

一页纸对照表

六个必须警觉的瞬间

时效性提醒

• EEVDF 取代 CFS：自 Linux 6.6（2023）起默认调度器已是 EEVDF。早于此的教材都写 CFS。两者调度实体都是 task，不影响结论。
• UMS 移除：Windows 11 起才真正移除 OS 层 UMS API；更早弃用的是 ConcRT 对它的使用，两件事别混。
• 数据的版本依赖：内核栈 16 KB、glibc 栈 2–10 MB、goroutine 栈 2 KB、Go 的 M 上限 10000——都是特定版本 / 架构的默认值，会随 ulimit、GOMAXPROCS、-Xss 变化。
• Li/Ding/Shen 的 3.4 μs：2007 年 Linux 2.6.17 + 当年硬件的数据。现代硬件绝对值更低，但"直接成本 μs 级、间接成本受 cache 主导"的结论依然成立。
• Scheduler Activations 的年份：会议版 SOSP 1991，期刊版 ACM TOCS 1992——同一工作，两个年份都对。