1. 进程和线程到底在解决什么问题——一个并发下载工具的“翻车”现场前几天带一位实习生调一个批量下载工具他用了Python的threading写了并发下载跑起来CPU占用率一直上不去网络也忽快忽慢最要命的是偶尔还会下载出损坏的文件。查了半天代码没发现问题最后发现是他对“进程”和“线程”这两个基本概念的边界没吃透在需要隔离任务资源的地方用了共享内存又在需要共享数据的地方起了多个进程两头都别扭。这就是“第8天“讲进程和线程时最值得先想清楚的问题这两个东西到底是为了解决什么才出现的答案是并发但并发不是”同时开几个循环“那么简单它背后涉及三件事——任务的并行执行、资源的隔离与共享、以及系统如何调度有限的计算资源。随便打开一台运行中的电脑操作系统里同时跑着几百上千个任务浏览器在渲染页面音乐软件在解码音频编辑器在后台索引文件这些任务各自需要独立的地址空间一个崩溃了不应该把整个系统带走但在一个任务内部比如浏览器里同时加载几十个标签页你又希望它们共享缓存、共享cookie、共享进程的公共资源而不是每个标签页都开一个完整进程。这就引出了两个不同粒度的设计进程是资源分配的最小单位线程是CPU调度的最小单位。进程像一整栋公寓楼有自己的墙、自己的水电表线程像楼里的房间住户共享楼道、水电基础设施但每户有自己的卧室和卫生间。如果你不理解“为什么需要进程”和“为什么还需要线程”后面学锁、学同步、学调度、学IO模型都会是空中楼阁。这一篇我按第8天的学习主线来写先讲进程的全套家底再讲线程与进程的差异然后钻进调度器内部看时间片轮转的真实场景最后聊并发编程里最容易踩的竞态条件和死锁问题并附一个可以直接动手做的小作业。适合正在学操作系统的学生、刚接触服务端开发的新人也适合那些“会用多线程但总出神秘Bug”的开发者。2. 进程的“家底”进程控制块、地址空间与状态流转2.1 一个进程在系统里到底长什么样操作系统要管理进程手里必须有一张“信息卡”这张卡叫进程控制块PCBProcess Control Block。你在教科书上看到的所有关于进程的描述什么PID、状态、优先级、上下文数据、打开的文件列表、内存界限全部存在这张卡里。操作系统不是在管理“正在运行的代码”而是在管理这一张张卡代码本身是静态的躺在外存里进程是动态的是“加载到内存、登记到PCB、被调度器选中执行”之后才产生的。PCB里最关键的几个字段我列一下进程标识符PID唯一标识一个进程ps命令看到的数字就是它。进程状态就绪、运行、阻塞、新建、终止调度器全靠它做决策。CPU上下文寄存器组的值、程序计数器、栈指针。进程被换下CPU时这些值必须完整保存下一次调度回来时才能无缝接上。内存管理信息代码段、数据段、堆栈段的基址和界限页表指针。资源清单打开的文件描述符表、信号处理函数表、挂起的信号集合。父子关系父进程PID、子进程链表这是fork之后进程树能维护起来的基础。如果你用ps -elf看一个正在运行的系统会看到TTY列、STAT列、PID和PPID这些字段绝大部分都来自PCB。2.2 进程的地址空间为什么进程之间不会互相踩到脚每个进程都拥有自己独立的虚拟地址空间这是进程隔离的根基。在32位系统上用户空间通常占0到3GB内核空间占3GB到4GB在64位系统上用户空间和内核空间各占一半左右具体比例取决于配置。进程看到的“地址”并不是物理内存的真实地址而是虚拟地址由CPU的MMU内存管理单元配合页表完成翻译。这样设计带来的好处非常实际一个进程因为野指针崩溃段错误只发生在它自己的虚拟地址空间里不会写坏别的进程的内存一个进程读取属于自己的内存也读不到别的进程的数据。进程间通信IPC所以麻烦正是因为这种隔离天生就把“数据共享”的捷径封死了——要么用管道、要么用消息队列、共享内存、信号量每种方案背后都有一层“跨越隔离墙”的代价。我很多时候喜欢用一个比喻进程像独立的单间公寓有独立的门锁邻居之间不能直接看到对方的家具。你要是想递东西给隔壁得通过公共走廊管道、物业信箱消息队列或者干脆买一套两个房间打通的房子共享内存代价就是失去了隐私隔离。2.3 状态转换里藏着“CPU为什么空转”的答案进程从诞生到结束会经历一系列状态变化新建New、就绪Ready、运行Running、阻塞Blocked、终止Terminated。几个状态之间的转换条件是理解系统性能问题的关键就绪 - 运行调度器从就绪队列里挑一个进程上CPU。运行 - 阻塞进程发起I/O操作读磁盘、读网络或等待某个事件主动让出CPU。运行 - 就绪时间片耗尽或者被更高优先级的进程抢占。阻塞 - 就绪I/O完成或等待的事件到达进程回到就绪队列排队。很多做后端开发的人问“为什么我的服务CPU不高但吞吐量上不去”答案往往藏在第二类转换里大量线程在等数据库I/O、等网络响应、等锁Healthy状态看起来很多但实际上全部处于阻塞状态CPU当然利用不起来。反过来如果你发现CPU一百个核全部打满程序还是慢那可能是计算密集任务被错误地拆分成了大量阻塞等待或者干脆就是调度策略没匹配上负载特征。2.4 实操验证用系统命令观察“进程的家底”纸上谈兵没用开了终端直接看。在Linux系统里ps -eo pid,ppid,stat,comm可以查看进程的基本状态与父子关系top -H -p PID可以查看某个进程内部所有线程的CPU占用pstree -p可以用树状视图查看进程的家族关系。用一个简单的操作就能亲身感受“状态转换”起一个sleep 100的进程第一次用ps看它的状态通常是S可中断睡眠也就是阻塞态因为它在sleep等待超时事件根本没占用CPU然后对一个死循环程序执行同样操作看到的状态往往是R运行态或就绪态在单核CPU的机器上它会把一个核吃满。这个对照实验非常简单但对理解“阻塞态与运行态”的区别特别有效。还需要注意僵尸进程Z和不可中断睡眠D僵尸进程是子进程已经终止但父进程还没调用waitpid回收其PCB信息所以它“死而不僵”占着PCB不释放D状态通常表示进程在内核态执行不可中断的I/O等待不能轻易被杀掉如果大量任务卡在D状态大概率是底层存储出了问题。这两类状态在排查线上故障时几乎每天都要打交道。3. 线程的实现方式与开销对比用户态、内核态以及被误解的GIL3.1 线程到底“轻”在哪线程是进程内部的一条执行流。同一进程内的多个线程共享代码段、数据段、堆内存和打开的文件只拥有自己独立的栈、寄存器上下文和程序计数器。正因为大部分资源是共享的创建线程比创建进程便宜得多进程创建要复制或写时复制地址空间、初始化页表、建立文件描述符表线程创建只需要分配一个栈和一套上下文通常快一个数量级。进程和线程的取舍我用一个表格帮你整理这也是我教新人的第一份速查卡对比项进程线程资源拥有的粒度独立的地址空间、文件表、信号表同进程内共享地址空间和文件表创建/销毁开销高涉及内存空间复制与页表初始化低只分配栈与上下文通信方式进程间通信管道、消息队列、共享内存等直接读写共享变量但要加锁隔离性强一个进程崩溃不影响其他进程弱一个线程越界可能拖垮整个进程CPU调度单位进程本身作为调度单位传统模型线程作为调度单位进程成为资源容器适用典型场景多租户隔离、不可信插件、计算密集分布式任务IO密集型并发、高度共享数据的并发模型这个表格值得收藏。真正开发的时候你需要先问自己一个问题这些任务之间要共享大量数据吗如果要共享线程大概率更合适如果任务之间独立性强、崩溃隔离要求高、甚至需要部署到不同机器上进程就是更好的选择。3.2 三种线程模型得能分清楚教科书上把线程模型分为三层用户级线程ULT、内核级线程KLT、混合模型。这三者的本质区别在于“线程的创建、调度、切换”是由谁完成的。用户级线程完全在用户空间由线程库管理内核完全感觉不到线程的存在它只看到一个进程。好处是切换不需要陷入内核特别快坏处是一个线程发起阻塞的系统调用如果线程库没有做好的调度可能整个进程都被阻塞。Go语言的goroutine可以粗略理解成一种由运行时管理的用户级线程但底层运行时还会把一批goroutine映射到若干内核线程上属于混合模型。内核级线程由操作系统内核直接调度每个线程都有独立的内核栈和上下文阻塞一个线程不会影响同一进程的其他内核线程。代价是每次切换都要跨越用户态与内核态边界开销大。Linux的pthread库创建出来的线程默认就是内核级线程实际映射到内核线程。混合模型结合两者用户级线程负责高并发逻辑内核线程负责真正跑在CPU上用户线程与内核线程通过多路复用映射。像Go、Java的虚拟线程Project Loom、Erlang的进程本质上都是混合模型的实践。面试的时候能把这三层讲清楚比背再多的八股文都有说服力。3.3 Python的GIL为什么多线程常常“并发但并行不了”提到Python多线程就绕不开GIL全局解释器锁。CPython解释器为了保证对共享内存对象操作的原子性设置了GIL一个进程内同一时刻只能有一个线程在执行Python字节码。多线程在CPU密集型计算场景下几乎不提升性能有时甚至更差因为线程切换本身有开销但在IO密集型场景下效果显著因为IO等待时线程会释放GIL另一个线程可以继续执行。GIL不是Python语言本身的属性而是CPython解释器的实现细节。Jython、IronPython没有GILPython的multiprocessing模块本质上通过创建多个进程绕开GIL达到并行。如果你用Python做计算密集型任务优先考虑multiprocessing或调用C扩展做网络爬虫、消息处理这类IO密集型任务threading、asyncio都是合理选择。我见过太多人一写Python并发就上threading跑了8个线程结果计算量翻倍性能反而下降。这里有一个判断口诀CPU密集看并行IO密集靠并发。前者要进程要并行后者要线程要事件驱动方向搞反了后面全是坑。3.4 一个小实验亲眼看到线程共享与进程隔离自己动手验证一次比看十篇文章都管用。用Python写一个例子import threading import multiprocessing shared_list [] def append_item(value): for _ in range(1000): shared_list.append(value) # 线程版两个线程改同一个列表 t1 threading.Thread(targetappend_item, args(A,)) t2 threading.Thread(targetappend_item, args(B,)) t1.start() t2.start() t1.join() t2.join() print(threads result len:, len(shared_list)) # 进程版两个进程各自有一份列表 def process_append(value): shared_list.append(value) print(process sees list:, shared_list) if __name__ __main__: p1 multiprocessing.Process(targetprocess_append, args(A,)) p2 multiprocessing.Process(targetprocess_append, args(B,)) p1.start() p2.start() p1.join() p2.join()运行结果中线程版的两个线程操作的是同一个shared_list最终长度接近2000进程版的每个进程看到的是一个独立的列表打印出来的内容各自只有一个元素。这个实验直观展示了共享与隔离的差异也暗示了一个问题共享虽然省事但并发修改同一份数据时不做同步控制最终长度很可能不是2000而是小于2000——这就是下一节要讲的竞态条件。4. 调度器的工作现场时间片耗尽之后发生了什么4.1 多级反馈队列教科书之外的真实调度模型调度器是所有进程和线程能否“公平、高效”运行的裁判。现代操作系统的调度算法普遍采用多级反馈队列MLFQ思路很简单设置多个不同优先级、不同时间片的队列高优先级队列时间片短低优先级队列时间片长新任务进入最高优先级队列任务在给定时间片内没执行完就降级到下一级队列低优先级队列的任务等待过久会被提升回高优先级队列防止饥饿。这套机制的精髓在于“反馈”调度器不知道一个任务是CPU密集还是IO密集只能通过行为去猜。一个任务频繁主动让出CPU比如在等网络响应说明它是IO密集应该留在高优先级队列让它快速响应一个任务一直占用满时间片说明它是CPU密集应该调到低优先级队列把CPU让给交互型任务。这就是为什么你的编辑器永远比后台编译任务更“跟手”。4.2 上下文切换并发系统的隐形开销上下文切换是把当前任务的寄存器、程序计数器、内核栈保存下来再恢复下一个任务的寄存器、程序计数器、内核栈。这个过程需要陷入内核态做一趟完整的状态保存与恢复。如果系统里线程数量过多、切换过于频繁CPU的很大一部分时间会花在“保存现场、恢复现场”上而不是真正执行任务。一组经验数据可以帮你直观感受一次线程上下文切换大概花费几微秒到几十微秒。看起来不多但如果一个进程有5000个线程每个线程时间片只有几毫秒高并发IO场景下每秒可能发生数万次切换CPU时间的相当比例就被白白吃掉。很多服务端程序“调大线程数性能反而下降”根源就在这里——线程数不是越多越好线程数是需要匹配任务类型和CPU核数的。4.3 Linux调度器的实际调参窗口Linux的CFS完全公平调度器并不直接使用“时间片”概念而是通过vruntime虚拟运行时间来保证公平每个可运行线程挂在红黑树上调度器总是选择vruntime最小的线程运行线程运行时间越长vruntime增长越快被选中的概率就越低。这个设计本质上和MLFQ的精神一致兼顾公平与响应速度。你可以通过几个实际窗口感知调度行为cat /proc/cpuinfo的processor列表告诉你系统有多少逻辑核绑核时根据这个编号设定CPU亲和性。nice -n 10 命令可以启动一个低优先级进程nice值范围-20到19数值越低优先级越高renice可以调整一个运行中进程的优先级。检查线程数cat /proc/进程PID/status里的Threads字段可以看进程起了多少线程如果这个数字异常大一般就意味着线程模型设计有问题。之前有次在测试环境排查一个高CPU服务发现2核机器上跑着800多个线程大部分线程在等同一把锁锁的持有者又把锁内的I/O操作做得很重。当时的处理思路不是简单“减少线程数”而是把任务模型从“每请求一线程”改成有界线程池队列异步化线程数降到64吞吐量反而翻了两三倍。这就是理解调度器之后能做出的合理决定让可运行线程数量约等于处理器核数量把等待型线程的占比降下来。5. 并发Bug排查实录从竞态条件到死锁的完整链路5.1 竞态条件共享数据写在错误的时间竞态条件是指多个任务访问共享数据且最终结果依赖于任务执行的精确时序。经典场景是“读改写”三步操作线程A读到值n线程B也读到值nA把n加1写入B把n加1写入最终n只增加了1而不是2。解决竞态条件的标准工具是锁Mutex、原子操作Atomic或者干脆不可变数据。加锁的粒度很重要锁的范围太大会导致并发度下降相当于把多线程退化成了串行锁的范围太小又覆盖不住资源保护的边界形成漏洞。我见过最典型的错误是“双重检查”写错先不加锁读一遍发现需要更新再进去加锁结果在检查与加锁之间数据已经被别的线程改了。这个问题的标准解法是双重检查加锁Double-Checked Locking但前提是语言和硬件的内存模型允许这样安全发布对象在Python这类有GIL的语言里做双重检查相对安全但在C里如果没处理好内存屏障照样出错。5.2 死锁四个必要条件一起出现就一定卡死死锁指一组线程中每个线程都持有对方需要的资源同时等待对方释放自己需要的资源结果全部永远阻塞。教科书给出的死锁四条件是互斥、持有并等待、不可抢占、循环等待。实际排错时只要破坏其中一个条件就能解除死锁最常见的手段是破坏循环等待——“所有线程按固定顺序加锁”。看一个构造出死锁的例子import threading lock_a threading.Lock() lock_b threading.Lock() def task1(): lock_a.acquire() print(task1 got lock_a) lock_b.acquire() print(task1 got lock_b) lock_b.release() lock_a.release() def task2(): lock_b.acquire() print(task2 got lock_b) lock_a.acquire() print(task2 got lock_a) lock_a.release() lock_b.release() t1 threading.Thread(targettask1) t2 threading.Thread(targettask2) t1.start() t2.start() t1.join() t2.join()如果两个线程交错执行task1拿到lock_a之后task2拿到lock_b两边再去拿对方手里的锁时就会一直等下去。解决办法是把两把锁的获取顺序统一成“先A后B”或者用with lock_a: with lock_b:嵌套语法保证释放顺序再或者使用Lock.acquire(timeout...)加超时超时后主动回滚而不是傻等。5.3 一次线上问题服务线程全部卡死的过程还原某次给一个小型任务系统排查故障现象是接口整体无响应请求全部超时。第一件事是用jstackJava场景或py-spy dumpPython场景抓线程栈发现大量线程都停在同一句代码上——在等一个数据库连接池的获取操作。继续查发现连接池被耗尽而持有着连接的那几个线程正在等一个内存队列里的任务处理完成那些任务又在等数据库连接释放。典型的“线程池耗尽循环等待”组合式死锁代码里任何单独一部分逻辑看起来都对但组合在一起就出问题。最终解法分两步第一步把数据库连接池的等待时间从无限等待改为5秒超时超时后快速失败第二步调整任务处理架构避免“处理线程”和“回调线程”互相等在共享资源上。这两步改完之后系统再也没有出现过全线卡死。排查并发问题最重要的手段永远是抓线程栈只靠看日志猜测是低效的线程栈会直接告诉你每条线程停在哪一行代码等待哪个资源谁持有这个资源。5.4 防呆清单并发代码发布前先给自己过一遍顺着上面的教训我整理了一份实践清单每次写并发代码都拿出来对照访问共享数据前是否明确加了锁锁的作用域是否覆盖了读改写全过程是否存在获取多把锁的场景获取顺序是否全局唯一等待外部资源数据库连接、网络响应、队列容量时是否有超时机制超时后的回滚逻辑是否完整线程池的线程数是否远大于CPU核数任务里是否大量出现阻塞等待是否存在一个线程在持锁状态下执行I/O操作如果有能否把I/O移出临界区进程退出时是否释放了所有资源子线程是否都做了join这六条不是空话每一条背后都对应一个我踩过的或者帮别人踩过的坑。你能把这几条真正落实并发代码的稳定性会上一大截。6. 第8天作业设计并实测一个多进程/多线程下载工具6.1 作业目标与预期掌握的能力作业本身不复杂但能逼你把这一天的知识点串起来。目标写一个命令行下载工具批量下载一批文本文件或图片要求支持多线程模式和通过multiprocessing实现的多进程模式并统计对比两种模式的耗时。掌握能力包括三块第一块是创建和控制并发任务线程池/进程池的创建、任务提交、结果收集第二块是资源限制与同步控制最大并发数、避免对共享输出文件造成写乱第三块是性能分析统计不同并发度下的耗时、CPU与IO占比解释为什么线程和进程在不同场景下表现不同。6.2 参考实现步骤与核心代码第一步准备一批测试文件列表。假设你有150个小文件需要下载用range(150)模拟即可。第二步分别用ThreadPoolExecutor和ProcessPoolExecutor写两个下载任务模块每个任务模拟下载随机sleep一段时间模拟网络IO把文件名写到共享日志时加锁。第三步固定测试环境同一批文件同样的网络条件分别用1、4、8、16、32个并发工作者跑一遍记录总耗时。可以用下面这段结构快速搭起来以线程版本为例import time import concurrent.futures def fetch_one(index): time.sleep(0.05) # 模拟网络等待 return index def run_thread_pool(workers): start time.time() with concurrent.futures.ThreadPoolExecutor(max_workersworkers) as executor: list(executor.map(fetch_one, range(150))) return time.time() - start for w in [1, 4, 8, 16, 32]: used run_thread_pool(w) print(fthread workers{w}, time{used:.2f}s)把ThreadPoolExecutor换成ProcessPoolExecutor再跑一遍同样的循环对比数据。6.3 测试结果怎么解读按我自己的实测数据在模拟纯IO等待的场景下多线程和多进程的提升都接近线性从64个并发开始提升幅度下降原因是切换开销和等待唤醒的调度开销开始占主导如果把这个任务改成纯计算比如大量浮点运算在多核机器上多进程的加速比明显高于多线程Python环境尤其明显因为GIL直接限制了线程并行能力。要求你在作业报告里必须回答三个问题第一为什么IO密集场景下线程能提升性能哪怕Python有GIL第二为什么计算密集场景下多线程总是输给多进程第三在什么情况下并发数继续增加性能反而下降把这3个问题答清楚说明你对进程线程的核心概念基本过关了。6.4 验收标准与常见失败模式你的作业需要提交三样东西代码、测试数据表格、结论说明。验收看三个点一是有没有用锁或者队列保证“写日志文件”不乱二是测试数据是否包含至少5组不同并发度三是结论是否解释了“为什么8个工作线程比1个线程快但32个线程反而慢”。我这些年带人看这类作业最常见的失败模式有两种。一种是所有耗时测试都是在同一台负载很高的机器上跑的结果数据无规律说服力几乎为零另一种是只测了线程模式没有做进程模式对照交上来的结论断了一条腿。我把这两条列出来就是提醒你取证是要讲环境一致性的跑测试前先关掉多余的服务把测试机空出来。6.5 进阶挑战有界线程池与队列异步化作业做完之后如果你还有余力可以挑战一个进阶方向重写下载模块不使用固定大小的ThreadPoolExecutor而是自定义一个有界任务队列队列满了先让生产者阻塞消费者固定在N个线程——体会一下“背压”对系统稳定性的价值。再往下走可以引入asyncio实现单线程内的高并发IO对比协程与线程的吞吐量差异。到这一步“第8天进程和线程”的内容就彻底从概念层面延伸到了工程实践层面。我个人的体会是进程和线程这一章是操作系统里“离代码最近”的一章但也是最容易被当成背概念跳过的一章。很多工作三年的人写并发程序靠搜索引擎拼凑出了问题连线程栈都不会抓就是当年没把PCB、状态机、调度、同步这几件事踏实吃过一遍。今天这篇的内容不少但核心就一句话——先搞清楚你要的是隔离还是共享再决定用进程还是线程决定了之后再考虑锁、队列和线程池的细节。这句话想明白了比记住一百个API都值钱。 
长河君 · 2026/10/14 23:38:41 · 阅读 1.2k 进程与线程核心解析：从PCB原理到并发Bug排查实战
1. 进程和线程到底在解决什么问题——一个并发下载工具的“翻车”现场前几天带一位实习生调一个批量下载工具他用了Python的threading写了并发下载跑起来CPU占用率一直上不去网络也忽快忽慢最要命的是偶尔还会下载出损坏的文件。查了半天代码没发现问题最后发现是他对“进程”和“线程”这两个基本概念的边界没吃透在需要隔离任务资源的地方用了共享内存又在需要共享数据的地方起了多个进程两头都别扭。这就是“第8天“讲进程和线程时最值得先想清楚的问题这两个东西到底是为了解决什么才出现的答案是并发但并发不是”同时开几个循环“那么简单它背后涉及三件事——任务的并行执行、资源的隔离与共享、以及系统如何调度有限的计算资源。随便打开一台运行中的电脑操作系统里同时跑着几百上千个任务浏览器在渲染页面音乐软件在解码音频编辑器在后台索引文件这些任务各自需要独立的地址空间一个崩溃了不应该把整个系统带走但在一个任务内部比如浏览器里同时加载几十个标签页你又希望它们共享缓存、共享cookie、共享进程的公共资源而不是每个标签页都开一个完整进程。这就引出了两个不同粒度的设计进程是资源分配的最小单位线程是CPU调度的最小单位。进程像一整栋公寓楼有自己的墙、自己的水电表线程像楼里的房间住户共享楼道、水电基础设施但每户有自己的卧室和卫生间。如果你不理解“为什么需要进程”和“为什么还需要线程”后面学锁、学同步、学调度、学IO模型都会是空中楼阁。这一篇我按第8天的学习主线来写先讲进程的全套家底再讲线程与进程的差异然后钻进调度器内部看时间片轮转的真实场景最后聊并发编程里最容易踩的竞态条件和死锁问题并附一个可以直接动手做的小作业。适合正在学操作系统的学生、刚接触服务端开发的新人也适合那些“会用多线程但总出神秘Bug”的开发者。2. 进程的“家底”进程控制块、地址空间与状态流转2.1 一个进程在系统里到底长什么样操作系统要管理进程手里必须有一张“信息卡”这张卡叫进程控制块PCBProcess Control Block。你在教科书上看到的所有关于进程的描述什么PID、状态、优先级、上下文数据、打开的文件列表、内存界限全部存在这张卡里。操作系统不是在管理“正在运行的代码”而是在管理这一张张卡代码本身是静态的躺在外存里进程是动态的是“加载到内存、登记到PCB、被调度器选中执行”之后才产生的。PCB里最关键的几个字段我列一下进程标识符PID唯一标识一个进程ps命令看到的数字就是它。进程状态就绪、运行、阻塞、新建、终止调度器全靠它做决策。CPU上下文寄存器组的值、程序计数器、栈指针。进程被换下CPU时这些值必须完整保存下一次调度回来时才能无缝接上。内存管理信息代码段、数据段、堆栈段的基址和界限页表指针。资源清单打开的文件描述符表、信号处理函数表、挂起的信号集合。父子关系父进程PID、子进程链表这是fork之后进程树能维护起来的基础。如果你用ps -elf看一个正在运行的系统会看到TTY列、STAT列、PID和PPID这些字段绝大部分都来自PCB。2.2 进程的地址空间为什么进程之间不会互相踩到脚每个进程都拥有自己独立的虚拟地址空间这是进程隔离的根基。在32位系统上用户空间通常占0到3GB内核空间占3GB到4GB在64位系统上用户空间和内核空间各占一半左右具体比例取决于配置。进程看到的“地址”并不是物理内存的真实地址而是虚拟地址由CPU的MMU内存管理单元配合页表完成翻译。这样设计带来的好处非常实际一个进程因为野指针崩溃段错误只发生在它自己的虚拟地址空间里不会写坏别的进程的内存一个进程读取属于自己的内存也读不到别的进程的数据。进程间通信IPC所以麻烦正是因为这种隔离天生就把“数据共享”的捷径封死了——要么用管道、要么用消息队列、共享内存、信号量每种方案背后都有一层“跨越隔离墙”的代价。我很多时候喜欢用一个比喻进程像独立的单间公寓有独立的门锁邻居之间不能直接看到对方的家具。你要是想递东西给隔壁得通过公共走廊管道、物业信箱消息队列或者干脆买一套两个房间打通的房子共享内存代价就是失去了隐私隔离。2.3 状态转换里藏着“CPU为什么空转”的答案进程从诞生到结束会经历一系列状态变化新建New、就绪Ready、运行Running、阻塞Blocked、终止Terminated。几个状态之间的转换条件是理解系统性能问题的关键就绪 - 运行调度器从就绪队列里挑一个进程上CPU。运行 - 阻塞进程发起I/O操作读磁盘、读网络或等待某个事件主动让出CPU。运行 - 就绪时间片耗尽或者被更高优先级的进程抢占。阻塞 - 就绪I/O完成或等待的事件到达进程回到就绪队列排队。很多做后端开发的人问“为什么我的服务CPU不高但吞吐量上不去”答案往往藏在第二类转换里大量线程在等数据库I/O、等网络响应、等锁Healthy状态看起来很多但实际上全部处于阻塞状态CPU当然利用不起来。反过来如果你发现CPU一百个核全部打满程序还是慢那可能是计算密集任务被错误地拆分成了大量阻塞等待或者干脆就是调度策略没匹配上负载特征。2.4 实操验证用系统命令观察“进程的家底”纸上谈兵没用开了终端直接看。在Linux系统里ps -eo pid,ppid,stat,comm可以查看进程的基本状态与父子关系top -H -p PID可以查看某个进程内部所有线程的CPU占用pstree -p可以用树状视图查看进程的家族关系。用一个简单的操作就能亲身感受“状态转换”起一个sleep 100的进程第一次用ps看它的状态通常是S可中断睡眠也就是阻塞态因为它在sleep等待超时事件根本没占用CPU然后对一个死循环程序执行同样操作看到的状态往往是R运行态或就绪态在单核CPU的机器上它会把一个核吃满。这个对照实验非常简单但对理解“阻塞态与运行态”的区别特别有效。还需要注意僵尸进程Z和不可中断睡眠D僵尸进程是子进程已经终止但父进程还没调用waitpid回收其PCB信息所以它“死而不僵”占着PCB不释放D状态通常表示进程在内核态执行不可中断的I/O等待不能轻易被杀掉如果大量任务卡在D状态大概率是底层存储出了问题。这两类状态在排查线上故障时几乎每天都要打交道。3. 线程的实现方式与开销对比用户态、内核态以及被误解的GIL3.1 线程到底“轻”在哪线程是进程内部的一条执行流。同一进程内的多个线程共享代码段、数据段、堆内存和打开的文件只拥有自己独立的栈、寄存器上下文和程序计数器。正因为大部分资源是共享的创建线程比创建进程便宜得多进程创建要复制或写时复制地址空间、初始化页表、建立文件描述符表线程创建只需要分配一个栈和一套上下文通常快一个数量级。进程和线程的取舍我用一个表格帮你整理这也是我教新人的第一份速查卡对比项进程线程资源拥有的粒度独立的地址空间、文件表、信号表同进程内共享地址空间和文件表创建/销毁开销高涉及内存空间复制与页表初始化低只分配栈与上下文通信方式进程间通信管道、消息队列、共享内存等直接读写共享变量但要加锁隔离性强一个进程崩溃不影响其他进程弱一个线程越界可能拖垮整个进程CPU调度单位进程本身作为调度单位传统模型线程作为调度单位进程成为资源容器适用典型场景多租户隔离、不可信插件、计算密集分布式任务IO密集型并发、高度共享数据的并发模型这个表格值得收藏。真正开发的时候你需要先问自己一个问题这些任务之间要共享大量数据吗如果要共享线程大概率更合适如果任务之间独立性强、崩溃隔离要求高、甚至需要部署到不同机器上进程就是更好的选择。3.2 三种线程模型得能分清楚教科书上把线程模型分为三层用户级线程ULT、内核级线程KLT、混合模型。这三者的本质区别在于“线程的创建、调度、切换”是由谁完成的。用户级线程完全在用户空间由线程库管理内核完全感觉不到线程的存在它只看到一个进程。好处是切换不需要陷入内核特别快坏处是一个线程发起阻塞的系统调用如果线程库没有做好的调度可能整个进程都被阻塞。Go语言的goroutine可以粗略理解成一种由运行时管理的用户级线程但底层运行时还会把一批goroutine映射到若干内核线程上属于混合模型。内核级线程由操作系统内核直接调度每个线程都有独立的内核栈和上下文阻塞一个线程不会影响同一进程的其他内核线程。代价是每次切换都要跨越用户态与内核态边界开销大。Linux的pthread库创建出来的线程默认就是内核级线程实际映射到内核线程。混合模型结合两者用户级线程负责高并发逻辑内核线程负责真正跑在CPU上用户线程与内核线程通过多路复用映射。像Go、Java的虚拟线程Project Loom、Erlang的进程本质上都是混合模型的实践。面试的时候能把这三层讲清楚比背再多的八股文都有说服力。3.3 Python的GIL为什么多线程常常“并发但并行不了”提到Python多线程就绕不开GIL全局解释器锁。CPython解释器为了保证对共享内存对象操作的原子性设置了GIL一个进程内同一时刻只能有一个线程在执行Python字节码。多线程在CPU密集型计算场景下几乎不提升性能有时甚至更差因为线程切换本身有开销但在IO密集型场景下效果显著因为IO等待时线程会释放GIL另一个线程可以继续执行。GIL不是Python语言本身的属性而是CPython解释器的实现细节。Jython、IronPython没有GILPython的multiprocessing模块本质上通过创建多个进程绕开GIL达到并行。如果你用Python做计算密集型任务优先考虑multiprocessing或调用C扩展做网络爬虫、消息处理这类IO密集型任务threading、asyncio都是合理选择。我见过太多人一写Python并发就上threading跑了8个线程结果计算量翻倍性能反而下降。这里有一个判断口诀CPU密集看并行IO密集靠并发。前者要进程要并行后者要线程要事件驱动方向搞反了后面全是坑。3.4 一个小实验亲眼看到线程共享与进程隔离自己动手验证一次比看十篇文章都管用。用Python写一个例子import threading import multiprocessing shared_list [] def append_item(value): for _ in range(1000): shared_list.append(value) # 线程版两个线程改同一个列表 t1 threading.Thread(targetappend_item, args(A,)) t2 threading.Thread(targetappend_item, args(B,)) t1.start() t2.start() t1.join() t2.join() print(threads result len:, len(shared_list)) # 进程版两个进程各自有一份列表 def process_append(value): shared_list.append(value) print(process sees list:, shared_list) if __name__ __main__: p1 multiprocessing.Process(targetprocess_append, args(A,)) p2 multiprocessing.Process(targetprocess_append, args(B,)) p1.start() p2.start() p1.join() p2.join()运行结果中线程版的两个线程操作的是同一个shared_list最终长度接近2000进程版的每个进程看到的是一个独立的列表打印出来的内容各自只有一个元素。这个实验直观展示了共享与隔离的差异也暗示了一个问题共享虽然省事但并发修改同一份数据时不做同步控制最终长度很可能不是2000而是小于2000——这就是下一节要讲的竞态条件。4. 调度器的工作现场时间片耗尽之后发生了什么4.1 多级反馈队列教科书之外的真实调度模型调度器是所有进程和线程能否“公平、高效”运行的裁判。现代操作系统的调度算法普遍采用多级反馈队列MLFQ思路很简单设置多个不同优先级、不同时间片的队列高优先级队列时间片短低优先级队列时间片长新任务进入最高优先级队列任务在给定时间片内没执行完就降级到下一级队列低优先级队列的任务等待过久会被提升回高优先级队列防止饥饿。这套机制的精髓在于“反馈”调度器不知道一个任务是CPU密集还是IO密集只能通过行为去猜。一个任务频繁主动让出CPU比如在等网络响应说明它是IO密集应该留在高优先级队列让它快速响应一个任务一直占用满时间片说明它是CPU密集应该调到低优先级队列把CPU让给交互型任务。这就是为什么你的编辑器永远比后台编译任务更“跟手”。4.2 上下文切换并发系统的隐形开销上下文切换是把当前任务的寄存器、程序计数器、内核栈保存下来再恢复下一个任务的寄存器、程序计数器、内核栈。这个过程需要陷入内核态做一趟完整的状态保存与恢复。如果系统里线程数量过多、切换过于频繁CPU的很大一部分时间会花在“保存现场、恢复现场”上而不是真正执行任务。一组经验数据可以帮你直观感受一次线程上下文切换大概花费几微秒到几十微秒。看起来不多但如果一个进程有5000个线程每个线程时间片只有几毫秒高并发IO场景下每秒可能发生数万次切换CPU时间的相当比例就被白白吃掉。很多服务端程序“调大线程数性能反而下降”根源就在这里——线程数不是越多越好线程数是需要匹配任务类型和CPU核数的。4.3 Linux调度器的实际调参窗口Linux的CFS完全公平调度器并不直接使用“时间片”概念而是通过vruntime虚拟运行时间来保证公平每个可运行线程挂在红黑树上调度器总是选择vruntime最小的线程运行线程运行时间越长vruntime增长越快被选中的概率就越低。这个设计本质上和MLFQ的精神一致兼顾公平与响应速度。你可以通过几个实际窗口感知调度行为cat /proc/cpuinfo的processor列表告诉你系统有多少逻辑核绑核时根据这个编号设定CPU亲和性。nice -n 10 命令可以启动一个低优先级进程nice值范围-20到19数值越低优先级越高renice可以调整一个运行中进程的优先级。检查线程数cat /proc/进程PID/status里的Threads字段可以看进程起了多少线程如果这个数字异常大一般就意味着线程模型设计有问题。之前有次在测试环境排查一个高CPU服务发现2核机器上跑着800多个线程大部分线程在等同一把锁锁的持有者又把锁内的I/O操作做得很重。当时的处理思路不是简单“减少线程数”而是把任务模型从“每请求一线程”改成有界线程池队列异步化线程数降到64吞吐量反而翻了两三倍。这就是理解调度器之后能做出的合理决定让可运行线程数量约等于处理器核数量把等待型线程的占比降下来。5. 并发Bug排查实录从竞态条件到死锁的完整链路5.1 竞态条件共享数据写在错误的时间竞态条件是指多个任务访问共享数据且最终结果依赖于任务执行的精确时序。经典场景是“读改写”三步操作线程A读到值n线程B也读到值nA把n加1写入B把n加1写入最终n只增加了1而不是2。解决竞态条件的标准工具是锁Mutex、原子操作Atomic或者干脆不可变数据。加锁的粒度很重要锁的范围太大会导致并发度下降相当于把多线程退化成了串行锁的范围太小又覆盖不住资源保护的边界形成漏洞。我见过最典型的错误是“双重检查”写错先不加锁读一遍发现需要更新再进去加锁结果在检查与加锁之间数据已经被别的线程改了。这个问题的标准解法是双重检查加锁Double-Checked Locking但前提是语言和硬件的内存模型允许这样安全发布对象在Python这类有GIL的语言里做双重检查相对安全但在C里如果没处理好内存屏障照样出错。5.2 死锁四个必要条件一起出现就一定卡死死锁指一组线程中每个线程都持有对方需要的资源同时等待对方释放自己需要的资源结果全部永远阻塞。教科书给出的死锁四条件是互斥、持有并等待、不可抢占、循环等待。实际排错时只要破坏其中一个条件就能解除死锁最常见的手段是破坏循环等待——“所有线程按固定顺序加锁”。看一个构造出死锁的例子import threading lock_a threading.Lock() lock_b threading.Lock() def task1(): lock_a.acquire() print(task1 got lock_a) lock_b.acquire() print(task1 got lock_b) lock_b.release() lock_a.release() def task2(): lock_b.acquire() print(task2 got lock_b) lock_a.acquire() print(task2 got lock_a) lock_a.release() lock_b.release() t1 threading.Thread(targettask1) t2 threading.Thread(targettask2) t1.start() t2.start() t1.join() t2.join()如果两个线程交错执行task1拿到lock_a之后task2拿到lock_b两边再去拿对方手里的锁时就会一直等下去。解决办法是把两把锁的获取顺序统一成“先A后B”或者用with lock_a: with lock_b:嵌套语法保证释放顺序再或者使用Lock.acquire(timeout...)加超时超时后主动回滚而不是傻等。5.3 一次线上问题服务线程全部卡死的过程还原某次给一个小型任务系统排查故障现象是接口整体无响应请求全部超时。第一件事是用jstackJava场景或py-spy dumpPython场景抓线程栈发现大量线程都停在同一句代码上——在等一个数据库连接池的获取操作。继续查发现连接池被耗尽而持有着连接的那几个线程正在等一个内存队列里的任务处理完成那些任务又在等数据库连接释放。典型的“线程池耗尽循环等待”组合式死锁代码里任何单独一部分逻辑看起来都对但组合在一起就出问题。最终解法分两步第一步把数据库连接池的等待时间从无限等待改为5秒超时超时后快速失败第二步调整任务处理架构避免“处理线程”和“回调线程”互相等在共享资源上。这两步改完之后系统再也没有出现过全线卡死。排查并发问题最重要的手段永远是抓线程栈只靠看日志猜测是低效的线程栈会直接告诉你每条线程停在哪一行代码等待哪个资源谁持有这个资源。5.4 防呆清单并发代码发布前先给自己过一遍顺着上面的教训我整理了一份实践清单每次写并发代码都拿出来对照访问共享数据前是否明确加了锁锁的作用域是否覆盖了读改写全过程是否存在获取多把锁的场景获取顺序是否全局唯一等待外部资源数据库连接、网络响应、队列容量时是否有超时机制超时后的回滚逻辑是否完整线程池的线程数是否远大于CPU核数任务里是否大量出现阻塞等待是否存在一个线程在持锁状态下执行I/O操作如果有能否把I/O移出临界区进程退出时是否释放了所有资源子线程是否都做了join这六条不是空话每一条背后都对应一个我踩过的或者帮别人踩过的坑。你能把这几条真正落实并发代码的稳定性会上一大截。6. 第8天作业设计并实测一个多进程/多线程下载工具6.1 作业目标与预期掌握的能力作业本身不复杂但能逼你把这一天的知识点串起来。目标写一个命令行下载工具批量下载一批文本文件或图片要求支持多线程模式和通过multiprocessing实现的多进程模式并统计对比两种模式的耗时。掌握能力包括三块第一块是创建和控制并发任务线程池/进程池的创建、任务提交、结果收集第二块是资源限制与同步控制最大并发数、避免对共享输出文件造成写乱第三块是性能分析统计不同并发度下的耗时、CPU与IO占比解释为什么线程和进程在不同场景下表现不同。6.2 参考实现步骤与核心代码第一步准备一批测试文件列表。假设你有150个小文件需要下载用range(150)模拟即可。第二步分别用ThreadPoolExecutor和ProcessPoolExecutor写两个下载任务模块每个任务模拟下载随机sleep一段时间模拟网络IO把文件名写到共享日志时加锁。第三步固定测试环境同一批文件同样的网络条件分别用1、4、8、16、32个并发工作者跑一遍记录总耗时。可以用下面这段结构快速搭起来以线程版本为例import time import concurrent.futures def fetch_one(index): time.sleep(0.05) # 模拟网络等待 return index def run_thread_pool(workers): start time.time() with concurrent.futures.ThreadPoolExecutor(max_workersworkers) as executor: list(executor.map(fetch_one, range(150))) return time.time() - start for w in [1, 4, 8, 16, 32]: used run_thread_pool(w) print(fthread workers{w}, time{used:.2f}s)把ThreadPoolExecutor换成ProcessPoolExecutor再跑一遍同样的循环对比数据。6.3 测试结果怎么解读按我自己的实测数据在模拟纯IO等待的场景下多线程和多进程的提升都接近线性从64个并发开始提升幅度下降原因是切换开销和等待唤醒的调度开销开始占主导如果把这个任务改成纯计算比如大量浮点运算在多核机器上多进程的加速比明显高于多线程Python环境尤其明显因为GIL直接限制了线程并行能力。要求你在作业报告里必须回答三个问题第一为什么IO密集场景下线程能提升性能哪怕Python有GIL第二为什么计算密集场景下多线程总是输给多进程第三在什么情况下并发数继续增加性能反而下降把这3个问题答清楚说明你对进程线程的核心概念基本过关了。6.4 验收标准与常见失败模式你的作业需要提交三样东西代码、测试数据表格、结论说明。验收看三个点一是有没有用锁或者队列保证“写日志文件”不乱二是测试数据是否包含至少5组不同并发度三是结论是否解释了“为什么8个工作线程比1个线程快但32个线程反而慢”。我这些年带人看这类作业最常见的失败模式有两种。一种是所有耗时测试都是在同一台负载很高的机器上跑的结果数据无规律说服力几乎为零另一种是只测了线程模式没有做进程模式对照交上来的结论断了一条腿。我把这两条列出来就是提醒你取证是要讲环境一致性的跑测试前先关掉多余的服务把测试机空出来。6.5 进阶挑战有界线程池与队列异步化作业做完之后如果你还有余力可以挑战一个进阶方向重写下载模块不使用固定大小的ThreadPoolExecutor而是自定义一个有界任务队列队列满了先让生产者阻塞消费者固定在N个线程——体会一下“背压”对系统稳定性的价值。再往下走可以引入asyncio实现单线程内的高并发IO对比协程与线程的吞吐量差异。到这一步“第8天进程和线程”的内容就彻底从概念层面延伸到了工程实践层面。我个人的体会是进程和线程这一章是操作系统里“离代码最近”的一章但也是最容易被当成背概念跳过的一章。很多工作三年的人写并发程序靠搜索引擎拼凑出了问题连线程栈都不会抓就是当年没把PCB、状态机、调度、同步这几件事踏实吃过一遍。今天这篇的内容不少但核心就一句话——先搞清楚你要的是隔离还是共享再决定用进程还是线程决定了之后再考虑锁、队列和线程池的细节。这句话想明白了比记住一百个API都值钱。