进程、线程与协程

• 进程是资源分配的基本单位，拥有独立地址空间；线程是 CPU 调度的基本单位，共享进程地址空间；协程是用户态协作式调度单元。
• 内核态切换（进程/线程）涉及内核态陷入、寄存器保存、内核栈切换、TLB/缓存失效；协程切换仅需用户态保存少量寄存器，成本极低。
• 三类实体在并发行、并发单元数量、通信复杂度的取舍。

进程是资源分配的基本单位，每个进程拥有独立的虚拟地址空间、文件描述符表、信号处理器等，进程间切换需要切换页表导致 TLB 失效，且需进入内核态，成本最高。线程是轻量级进程，是 CPU 调度的最小单位，同一进程内的线程共享地址空间与大部分资源，切换只需切换内核栈与寄存器，无需切换页表，成本显著低于进程。协程是用户态可见的协作式并发单元，由用户态调度器（如 Go 的 runtime、Python 的 asyncio）管理，切换完全在用户态完成，只保存少量非易失寄存器与栈指针，成本最低（纳秒级）。从地址空间看，进程彼此隔离、线程共享、协程共享；从调度主体看，进程与线程由内核调度、协程由用户态库调度；从切换成本看，进程 > 线程 > 协程。

三者的本质差异源自"资源与调度的绑定关系"。进程把资源隔离与调度捆绑在一起，代价是隔离带来的切换开销；线程把调度从资源隔离中剥离出来，共享资源换取低成本切换；协程进一步把调度移动到用户态，由编译器/运行时自行管理，代价是单核内无法真正并行（仍需底层线程支撑）。理解这一条主线能解释为何现代语言（Go、Rust async）普遍采用"轻量级用户态任务 + 少量内核线程"的组合模型。

• 管道（匿名/命名）基于字节流，一次内核拷贝，适合父子进程单向简单传输。
• 共享内存性能最高，但需配合信号量同步，适合大数据量高频通信。
• Socket 支持跨主机通信，需经协议栈与网络协议，性能较低但通用。

匿名管道（pipe）用于有亲缘关系的进程，半双工字节流，数据经内核缓冲，适合简单单向传输；命名管道（FIFO）允许无关进程通过文件系统路径通信。消息队列以消息为单位传递，带类型与优先级，在内核中维护，适合少量结构化消息，但需两次拷贝（用户态→内核→用户态）。共享内存（mmap/shmat）将同一物理页映射到多个进程地址空间，省略内核拷贝，是吞吐最高的 IPC，但必须用信号量或锁同步以避免竞态。信号量主要用作同步原语而非数据传输。Socket 基于文件描述符，支持本机与跨主机，通过 TCP/UDP 协议栈通信，通用性最强但涉及协议处理与拷贝，性能相对较低。性能排序大致为：共享内存 > 管道/消息队列 > Socket；按通用性与跨主机能力则相反。

选择 IPC 时应权衡"吞吐、同步复杂度、跨主机能力"。数据量大且单机高频场景选共享内存；简单单向低延迟选管道；跨进程结构化消息选消息队列；通用与跨主机选 Socket。TCP 与共享内存之间通常还有 zero-copy、DPDK 等技术进一步优化，但核心仍是"减少数据拷贝次数"这一主线。

• 开销构成：寄存器保存/恢复、内核栈切换、页表切换（仅跨进程）导致的 TLB 失效、cache 冷失效。
• 测量手段：perf/内核 tracepoint、切换次数统计、缓存命中率观测。
• 减少手段：避免频繁切换、增大时间片、使用协程/用户态调度、CPU 亲和性、减少并发过度。

线程上下文切换的开销包括：CPU 寄存器组（通用寄存器、程序计数器、状态字）的保存与恢复；内核态与用户态之间的陷入与返回；切换内核栈；若发生在不同进程的线程间，还需切换页表（CR3），导致 TLB 完全失效，后续内存访问全部走慢路径；同时 L1/L2 缓存因访问地址空间改变而失效，重新加载指令与数据。跨进程切换的 TLB 刷新与缓存冷失效是主要成本，可达数千时钟周期。测量上可用 perf 的 context-switches 事件、Linux 的 /proc/stat ctxt 计数、或 pmu 的 cache-miss 指标。减少手段包括：把线程数控制在合理范围避免过度切换；增大时间片减少强制切换频率；采用用户态协程把切换降到用户态；用 CPU 亲和性（affinity）让线程固定核上以减少迁移与缓存失效；对休眠/唤醒激烈的场景做批量唤醒。

切换开销的本质是"硬件状态无法复用"：寄存器需要保存是必须的，但 TLB 与缓存失效才是真正昂贵且可优化的部分。因此减少切换的目标不是节省几条寄存器指令，而是尽量保持 TLB/cache 命中，这解释了为何协程、亲和性、批量调度在工程上被广泛采用。

• 切换成本：进程 > 线程 > 协程。
• 资源占用：进程占独立地址空间与资源，线程共享进程资源，协程仅需独立栈（通常几 KB 到几十 KB）。
• 通信方式：进程靠 IPC，线程靠共享内存+锁，协程靠共享变量与消息传递/通道。

上下文切换成本上，进程因需切换页表并刷新 TLB/缓存而最高，线程次之（无需换页表），协程最低（纯用户态保存寄存器）。资源占用上，进程包含完整的地址空间、文件表、信号、全局资源，开销大；线程共享进程的堆与全局区，仅保留独立栈与寄存器上下文，开销小；协程进一步只维护一个轻量栈（Go 协程栈初始仅 2KB 且可动态增长），可轻松创建数十万乃至百万级。通信方式上，进程间必须通过管道、消息队列、共享内存、Socket 等 IPC；线程间通过共享内存配合锁/条件变量/原子操作；协程间通过共享变量或消息通道（如 Go channel）通信，天然适合协作式并发。三者并非互斥，实践中常组合使用，如"多进程 + 进程内多线程 + 线程内多协程"。

该对比是通识重点，核心记忆点是"进程重资源隔离、线程轻量共享、协程极轻量协作"。三者资源与成本依次递减，灵活性与规模上限依次递增，选用时应结合并发度、隔离性与性能要求综合判断。

• Linux 采用 1:1 线程模型，线程由 clone 创建，共享地址空间，内核以 task_struct 对应每个线程。
• tgid（线程组 id）即用户视角的 pid（主线程 id），各线程的 pid 不同但 tgid 相同。
• 进程组（process group）用于作业控制与信号分发，与线程组（thread group）是不同概念。

Linux 内部没有独立的"线程"内核对象，每个线程都是一个 task_struct（轻量级进程），由 clone 系统调用创建，通过 CLONE_THREAD 等标志共享地址空间、文件描述符等资源，因此称"轻量级进程"。用户视角的 pid 实际是内核的 tgid（线程组 id，即创建线程组的主线程 pid）；组内各线程各自拥有唯一的内核 pid，但共享同一个 tgid。getpid() 返回的是 tgid，gettid() 返回每个线程自己的 pid。线程组（thread group）即一组共享 tgid 的线程，用于信号投递（信号发给进程即发给该组）；而进程组（process group）是作业控制概念，由 setpgid 创建，一组进程共享一个 pgid，用于终端信号（如 Ctrl+C 发给整个前台进程组）的广播。两者完全不同：线程组是调度/信号共享单位，进程组是作业控制单位。

理解"pid 是用户抽象、tgid/内部 pid 是内核实现"是本知识点的关键。Linux 用统一 task_struct 实现线程使得调度器无需区分进程与线程，但引入了 tgid 与 pid 的区分；进程组与线程组又是两个容易混淆但语义不同的概念，面试中应能清晰区分。

• 孤儿进程：父进程先退出，子进程被 init（PID 1，或 systemd/子 reaper）收养。
• 僵尸进程：子进程已退出但父进程未调用 wait/waitpid 回收其退出状态，内核保留 task_struct 与退出码。
• 僵尸进程无法被 kill 原因：其已死亡，kill 的信息只存在于内核等待父进程读取的退出状态中。

孤儿进程是父进程先于子进程退出，子进程被系统 init 进程（现代 Linux 为 systemd 或通过 subreaper 机制）收养，孤儿进程本身可正常运行，由 init 负责回收。僵尸进程是子进程已退出、但父进程未调用 wait/waitpid 读取其退出状态，此时内核为保存退出码与资源统计仍保留该 task_struct 的占位记录，进程进入 Z 状态。僵尸进程无法被 kill -9 清除，因为它已经死亡，kill 信号没有任何可投递的目标，其"存在"只是内核待父进程回收的一段退出状态记录；真正清除僵尸的办法是让父进程调用 wait 回收，或直接杀死父进程使僵尸被 init 收养并回收。若父进程长期不回收，可通过杀死父进程或重启来清理。

关键区分是"孤儿进程还在运行、僵尸进程已死"。僵尸进程占据的只是少量 PCB 内存，但大量堆积会耗尽 PID 表。根治需父进程正确 wait，或用 SIGCHLD 信号处理、设置 SIG_IGN 使子进程自动回收。这块是运维与语言运行时（如 Node、Java 的子进程管理）常见问题。

• 1:1：每个用户线程对应一个内核线程，并发强但成本高。Linux pthread 采用 1:1。
• N:1：多个用户线程映射到一个内核线程，切换快但无法利用多核并行，且一个阻塞全组阻塞。
• M:N：M 个用户线程映射到 N 个内核线程，兼顾灵活与并行，但实现复杂（两级调度）。

1:1 模型每个用户线程绑定一个内核线程，调度由内核负责，能充分利用多核，但创建与切换成本高，线程数受限；Linux pthread 即此模型。N:1 模型多个用户线程复用一个内核线程，由用户态库调度，切换极快、开销小，但无法并行利用多核，且任何一个线程阻塞系统调用会阻塞整组。M:N 模型将 M 个用户线程映射到 N 个内核线程，由用户态运行时调度器在两级间调度，兼顾并行性与大规模并发，但实现复杂、易有死锁与调度公平性问题。现代语言运行时多采用以 M:N 为思想、以"协程/Goroutine + 内核线程池"为落地的模型：Go 的 GPM 模型把大量 goroutine 调度到少数内核线程（P 上），遇到阻塞调用时换出线程；Java 的虚拟线程（Loom）同样把虚拟线程映射到平台线程组成的池；Rust async 则以 N:1 或 M:N 的异步执行器实现。整体趋势是"牺牲一点调度可控性，换取大规模并发与极低切换成本"。

选择映射模型是在"并行能力、线程规模、切换成本、实现复杂度"之间权衡。1:1 强并行但规模受限；N:1 高效但无并行；M:N 是理想但复杂。现代运行时用 M:N 思想 + 用户态调度获得了百万级并发，这是面试中记得住"为什么 Go 能扛高并发"的答案支点。

• TLS 为每个线程提供独立的变量副本，通过段基址（FS/GS）或线程控制块（TCB）访问。
• 线程栈大小默认约 8MB（Linux），在虚拟地址空间中为每个线程预留独立栈区域。
• 虚拟地址空间充裕（64 位 128TB 用户态），但线程栈与 TLS 均吃虚拟内存，线程过多会耗尽虚拟地址空间或触发栈溢出。

TLS（thread-local storage）在每个线程拥有独立的变量副本，通过把线程控制块（TCB，含 TLS 基址）放在线程栈的起始地址附近，并由 FS/GS 段寄存器或特殊寄存器指向，使 __thread 变量能以"基址 + 偏移"快速访问。每个线程在虚拟地址空间中预留独立的栈区域（Linux 默认 ulimit -s 约 8MB），栈顶向下增长，栈底附近存放 TCB。在 64 位 Linux 下用户态虚拟地址空间约 128TB，理论上可容纳大量线程栈；但线程栈是"预留虚拟内存、按需提交物理内存"，因此线程数受虚拟地址空间与物理内存双重限制。若为每个线程预留 8MB 栈，约 1600 万线程就可耗尽 128TB 虚拟空间；实际上线程过多主要受 PID 上限、物理内存与内核栈限制。栈溢出时因 guard page 的存在会触发 SIGSEGV。

该题考察"虚拟内存按需分配"与"线程资源"的结合。TLS 与栈都占用虚拟地址空间但未必立即占用物理内存，因此理解"虚拟内存预留 vs 物理内存提交"是核心。线程栈大小可通过 ulimit -s 或 pthread_attr_setstacksize 调整，权衡栈大小与可创建线程数。

• 进程/线程切换需陷入内核态，由内核调度器完成，成本高。
• 协程切换在用户态由运行时完成，不陷入内核，成本低。
• 内核态切换含系统调用边界、调度器运行、硬件上下文切换；用户态切换仅保存寄存器与栈。

进程与线程的切换必须由内核调度器完成：CPU 需要从用户态陷入内核态（特权级切换），保存当前线程的寄存器到内核栈，内核调度器选择下一个运行线程，再从内核态返回用户态并恢复其寄存器。整个过程跨越用户态/内核态边界，涉及系统调用或中断路径，成本高。协程的切换完全在用户态进行：由协程运行时（如 Go runtime、Python asyncio）主动保存当前协程的寄存器与栈指针，切换到目标协程，全程不发起系统调用、不进入内核态，成本仅有数十条指令，因此比内核线程切换快一到两个数量级。也正因协程由用户态协作式调度，协程本身无法并行执行，需要底层线程支撑才能真正利用多核。

"是否陷入内核态"是切换成本差异的根本来源。内核态调度具有优先级、抢占、公平性等完整能力，代价是昂贵；用户态调度便宜但缺乏硬件抢占与并发。实践中用"协程承载高并发、少而精的线程承载并行"来各取所长。

• 虚拟地址空间布局：代码段、数据段、堆、内存映射区、栈、内核区。
• 共享库通过 mmap 映射到每个进程的地址空间，物理页共享、虚拟地址不同。
• 动态链接库的位置由 ASLR 随机化，兼容性依赖 PIC 与重定位。

进程的虚拟地址空间从低到高大致为：代码段（.text）、已初始化数据段（.data）、未初始化数据段（.bss）、堆（向上增长）、内存映射区（mmap 区，含共享库、共享内存、文件映射）、栈（向下增长）、与内核保留区。共享库（如 libc）被加载到每个进程的 mmap 区，物理内存中的页被多个进程共享（只读页），但每个进程的虚拟地址不同，经页表映射到同一物理页。现代系统启用 ASLR 使共享库、堆、栈的加载基址随机化，降低 ROP 等攻击可行性；共享库代码需编译为位置无关代码（PIC）以便在不同基址下重定位。动态链接器（ld.so）在进程启动时完成库的映射与符号解析。

该题考察内存布局这个基础，重点是"虚拟地址空间是按需映射、物理页共享"的思想。共享库的"物理共享、虚拟独立"映射机制是理解内存占用、ASLR、动态链接的钥匙。栈与堆相向增长、中间是 mmap 区这一布局也决定了 mmap 使用地址空间的分配顺序。

• R 运行/就绪、S 可中断睡眠、D 不可中断睡眠、T 停止、Z 僵尸。
• D 状态进程处于内核态不可中断的 IO 等待，信号无法被处理，因此 kill 无效。
• 常见原因：内核态文件系统/网络 IO 阻塞、NFS 卡住、磁盘 IO 挂起、特定驱动等待。

ps 状态中：R 表示运行或就绪；S 表示可中断睡眠，进程等待某一事件，能被信号唤醒；D 表示不可中断睡眠，进程处于内核态等待 IO 完成，此类期间信号被挂起无法处理；T 表示被停止（如 Ctrl+Z 或收到 SIGSTOP）；Z 表示僵尸进程。D 状态进程无法被 kill 的原因是该进程正处于内核某一不可中断的调用路径（如等待磁盘/网络 IO 返回），内核代码在返回前不会处理信号，因此 SIGKILL 也无法生效。常见诱因包括：NFS 挂载的目标服务器不可达导致 IO 挂起、磁盘硬件故障或 RAID 卡死、块设备 IO 长期无响应、某些驱动阻塞。处理方式一般是从根因下手（修复 NFS/磁盘/驱动），严重时往往需重启；可用 ps 的 wchan 字段与 /proc//stack、内核 trace 定位阻塞路径。

D 状态是"内核承诺必须完成 IO 的原子性等待"的体现——若在 IO 中途被杀，内核状态可能不一致。因此操作系统选择在该区间忽略信号。区分 S 与 D 的关键是"能否被信号打断"：S 可打断、D 不可打断。本题与运维排查（D 状态进程堆积）紧密结合。

• 内核线程切换在软中断/中断路径中保存线程上下文到内核栈，切换 CR3 与内核栈。
• TSS 仅用于 RPL0 栈指针（内核栈基址）与 IO 位图，不再用于硬件任务切换。
• 硬件任务切换（task gate/TR）切换整组寄存器开销大且不够灵活，现代 OS 用软件切换。

在 x86 上，线程切换由内核软件完成：当发生时钟中断或系统调用时，CPU 从用户态进入内核态，使用 TSS 中记录的 Ring0 栈（内核栈）作为新的栈指针，随后内核在软中断（switch_to）中把当前线程的寄存器、程序计数器、栈指针保存到当前线程的内核栈，选择下一个线程，恢复其上下文并切换用户态 CR3（跨进程时）与 RSP。TSS（Task State Segment）在现代 OS 中只用于两件事：一是提供特权级 0 栈基址（内核栈），供用户态→内核态切换时空栈使用；二是保存 IO 位图。现代 OS 不再使用 TSS 的硬件任务切换机制（task switch / task gate），因为硬件切换会一次性保存/恢复全部寄存器并切换 TSS，开销大、不够灵活，且不便与内核自己的调度器逻辑配合；以内核软件 save/restore 上下文的方式更灵活、可控，能按需保存寄存器。

理解"TSS 在现代 OS 中退化"要抓住：x86 硬件任务切换是"重而全"的机制，而软件切换是"轻而可裁剪"的，后者更符合现代内核的调度需求。TSS 保留的"内核栈指针"功能是进入内核态所必需的，这是它未被完全移除的原因。该题考察对硬件机制与软件实现的深层理解。

• 并发是逻辑上的交错执行（微观可交替），并行是物理上的同时执行（多核）。
• 单核只能并发不能并行；多核才能并行。
• 利用并行需拆分任务、减少共享数据竞争、使用无锁/分区/任务并行模式。

并发（concurrency）是指多个任务在时间上交错执行的能力，重点在于"程序结构上可同时处理多个任务"，即使单核上宏观交替也算并发；并行（parallelism）是指多个任务在物理上同时执行，必须有多个计算单元（多核/多 CPU）。因此单核系统可以并发但无法并行，多核系统既支持并发也支持并行。要利用多核并行，需要把任务拆分到独立的线程/进程或数据分区，使各核同时执行不同任务；同时要减少共享可变状态以避免竞争与锁竞争，可借助无锁数据结构、读写锁、数据分片（如分区并行 map-reduce）、任务并行（线程池）等；CPU 密集任务用并行提升吞吐，IO 密集任务更多靠并发隐藏延迟。Go 的 goroutine、Java 的并行流、OpenMP 等都是利用并行的工具。

"并发≈结构、并行≈执行"是理解两者的钥匙。面试常问"并发与并行区别"，答出"并发处理多个任务、并行同时执行多个任务，单核可并发不可并行"即为要点。多核利用的本质是"并行度"与"同步开销"的平衡——拆分粒度太细反而因同步争用损失性能。

• 调度者不同：线程由内核抢占式调度，协程由用户态运行时协作式调度。
• 规模与成本：线程数受内核限制（数千到数万），协程可轻松百万级且切换成本极低。
• 适用场景：线程适合 CPU 密集/需真并行或调用阻塞系统库；协程适合高并发 IO、大量连接。

调度模型上，线程由内核抢占式调度，可随时被时间片/高优先级抢占，适合并行与长时间 CPU 计算；协程由用户态运行时协作式调度，只有在协程主动让出（如 await、yield）或发生阻塞调用时才切换，非抢占式。规模与成本上，线程每个需内核栈与独立 PCB，创建与切换要进内核，数量达万级后开销明显；协程仅需轻量栈（可小至几 KB），切换在用户态，可创建数十万甚至百万级。因此：线程适合需要真正并行、调用阻塞式系统库（如文件 IO、老式网络库）、对 CPU 占用高且需要内核调度的任务；协程适合高并发 IO 场景（大量网络连接、微服务网关、异步 Web 服务），用少而精的线程承载协程规避阻塞。实践中常"线程池 + 协程"组合，以少量内核线程承载大量协程。

选择协程或线程的关键是"并发规模与阻塞行为"。高并发 IO 场景协程大幅降低线程/内存开销并避免线程切换；需要利用多核或调用阻塞库时需线程或异步桥接。现代语言（Go 的 goroutine、Java 虚拟线程、Python asyncio）简化了二者结合，但底层仍是"协程 + 池化线程"。

• fork 复制父进程创建子进程，现代 Linux 用 COW 使父子共享页，仅在写入时复制。
• exec 用新程序替换进程映像，保留进程号与文件描述符。
• fork 后 exec 的典型组合避免了为中间态支付复制成本。

fork 系统调用复制当前进程创建子进程，子进程继承父进程的地址空间、文件描述符、环境变量等。为降低复制成本，现代系统采用写时复制（COW）：fork 时父子进程的页表项都标记为只读，并共享同一物理页；当任一进程写入某页时，触发缺页异常，内核才复制该物理页并重新映射，从而避免复制父进程全部内存。用 vfork 或"fork 后立即 exec"的组合可进一步避免无谓复制。exec 系列（execve）用新的可执行文件替换当前进程的代码、数据、堆、栈，但保留进程号（PID）与已打开的文件描述符等资源。典型模式是父进程 fork 子进程，子进程立即 exec 加载新程序，由于子进程在 exec 前几乎不写内存，COW 使 fork 十分廉价，这一"fork+exec"组合是 Unix 创建进程的标准方式。

COW 是零拷贝思想的体现：把"复制内存"推迟到真正写入时，显著降低 fork 成本。理解"fork 建立共享、exec 替换映像、进程号不变"三者的配合，是理解 Unix 进程创建与 shell 执行命令原理的基础。COW 也常与内存映射、守护进程、容器等话题关联。

• 管道：字节流、单向、亲缘进程，适合简单传输。
• 共享内存：大数据量高频，需同步。
• 消息队列：结构化消息、带类型，适合少量消息。

管道传输字节流，匿名管道仅限有亲缘关系的进程、单向通信，命名管道（FIFO）支持无关进程，实现简单、适合父子进程间简单数据传递。共享内存把同一物理页映射进多个进程地址空间，省去内核拷贝，吞吐最高，适合大数据量高频传递，但必须配合信号量/锁同步。消息队列以消息为单位传递，每条带类型与优先级，在内核中排队，适合传递结构化、数量较少的消息，但存在两次拷贝的开销。信号是一种异步通知机制，用于通知进程发生某事件（如 SIGINT、SIGUSR1），不能传递复杂数据，发信号者无法确认接收，适合轻量事件通知与进程控制。选择时按"数据量、结构、同步需求、亲缘关系"综合判断。

四种 IPC 可归为"数据传输（管道/共享内存/消息队列）"与"事件通知（信号）"两类。共享内存强调吞吐、管道强调简单、消息队列强调结构化、信号强调异步通知。掌握各自"一次还是两次拷贝、是否需要同步、是否亲缘"即可应对。

• 互斥锁：保证互斥访问临界区，任一时刻仅一个线程持锁。
• 条件变量：用于等待某条件成立，需与互斥锁配合，避免忙等。
• 读写锁：区分读/写，读读可并行、读写互斥，提升读多写少场景吞吐。

互斥锁（mutex）保证临界区互斥，同一时刻只有一个线程能持锁进入，其余线程阻塞等待，用于保护共享资源的一致性。条件变量（condition variable）用于线程间等待某个状态条件成立，必须与互斥锁配合使用：线程先加锁，若条件不满足则调用 wait 原子地释放锁并阻塞，其他线程在条件变化后调用 signal/broadcast 唤醒；这种"等待-通知"模式避免了忙等，也解决了"丢失唤醒"问题。读写锁（rwlock）允许多个读者同时进入临界区，但写者独占；当读者远多于写者时，相比互斥锁能显著提升并发读吞吐，但实现与公平性更复杂（需处理读者与写者的优先级）。三者的选择：简单互斥访问用互斥锁；需要等待条件用条件变量；读多写少用读写锁。

三者是线程同步的基础原语。互斥锁解决"互斥"，条件变量解决"等待与通知"，读写锁优化"读多写少"。理解条件变量必须与互斥锁配合（wait 原子释放锁）是关键，而读写锁的优化收益来源于"读读并行"的放宽。