开篇从“一个程序无法同时干两件事”说起你有没有想过你在浏览器里刷网页的同时后台的播放器在放歌微信在接收消息杀毒软件在扫描磁盘——这些都是同时发生的。但你的CPU一共就那么多核它怎么做到“一心多用”的答案是操作系统用一种非常聪明的机制在**“骗”你它让每个程序轮流占用CPU切换得足够快快到你以为它们是并行跑在同一个核心上的。而这个机制的核心就是进程**。进程是操作系统里最重要的抽象概念之一也是任何一门《操作系统》课程无论如何都绕不开的章节。很多初学者刚开始接触“进程状态”的时候会觉得状态图就那么几个圈、几条线背一背就能过考试。但实际一做实验、一写多线程代码就发现不对劲了为什么程序卡住了为什么明明有多个进程却跑不满CPU为什么kill杀不掉某个进程这背后全是对进程状态与管理的理解不够深入。这篇文章就是我的操作系统学习笔记整理既包含课程核心知识点的拆解也会把我在实验和项目里踩过的坑、用过的排查命令、真正有效的学习方法写出来。内容适合正在学操作系统的大学生、准备考研408计算机统考的同学以及工作中想真正搞懂进程管理、排查线上问题的程序员。通篇不讲废话直接上干货。1. 进程到底是个什么东西从程序到进程的“质变”1.1 程序是死的进程是活的先打一个非常生活化的比方。程序文件比如你下载的wechat.exe就像一张菜谱它躺在硬盘上是静态的不会自己动。而进程就像一位厨师正在照着菜谱做菜——他占用了厨房内存、拿着厨具CPU寄存器、正在处理食材数据每一步都有实实在在的状态。操作系统管理的不再是“菜谱”而是“厨师”的整个工作状态。所以进程是程序的一次执行过程是系统进行资源分配和调度的基本单位。这句话是教材里的标准定义但它有几个关键细节值得拆开说“一次执行过程”意味着同一个程序可以被启动多次产生多个不同的进程。比如你开了三个终端窗口每个窗口都在运行vim那就有三个vim进程它们彼此独立互不干扰。“资源分配”指的是每个进程都有自己独立的地址空间、打开的文件描述符、环境变量、工作目录等。进程之间默认是相互隔离的一个进程崩溃了不会直接导致另一个进程崩溃。“调度”指的是CPU资源是怎么分配给多个进程使用的。谁先用、用多久、什么时候被换下去这些都由操作系统的调度器决定。理解了这几点你就能明白为什么说进程是操作系统的核心——文件管理、内存管理、设备管理最终都要服务于“让这些进程能好好运行”这件事。1.2 认识进程的“身份证”PCB每个进程在操作系统内部都有一个对应的数据结构来记录它的全部信息这个结构就是PCB进程控制块Process Control Block。你可以把它理解为进程的“病历本”或者“身份证档案”。PCB里到底装了什么我把它分成四类信息方便记忆信息类别具体内容作用进程标识符PID、父进程PPID、用户ID等唯一区分每个进程处理机状态通用寄存器值、程序计数器PC、状态字等保存进程被换下CPU时的现场下次换上来能接着跑进程调度信息进程状态、优先级、等待原因等调度器根据这些信息决定谁上CPU进程控制信息内存边界、打开的文件列表、I/O设备列表等管理和回收进程资源这里最重要的一个知识点是PCB是进程存在的唯一标志。也就是说一个进程从被创建开始操作系统为它建立一个PCB进程结束时操作系统收回PCB。你哪怕看不到进程在跑什么代码只要PCB还在这个进程就算存在。这个机制也解释了操作系统的经典面试题“操作系统是怎么知道某个内存地址属于哪个进程的”“进程崩溃了为什么其他进程不受影响”答案都指向PCB——系统通过PCB来管理进程所拥有的全部资源进程间的隔离就是靠这套独立的PCB资源记录实现的。1.3 进程和线程先分清这两个概念很多教材会把进程和线程放在一起讲很多初学者也容易混。我的理解是这样的进程是资源分配的单位线程是CPU调度的单位。一个进程内部可以包含多个线程这些线程共享进程的地址空间和资源比如内存、文件句柄但每个线程有自己的栈和寄存器上下文。你可以把进程想象成一家公司线程就是公司里的员工。公司拥有办公场地和设备资源员工负责具体干活占用CPU。员工之间共享公司的资源但每个员工的工作状态是独立的。这个区分在学习进程状态的时候尤其重要。因为你后面会看到Linux里的top命令显示的线程状态、Java里Thread.State的枚举值都和操作系统的进程状态密切相关。站在操作系统层面线程本质上也是一种“轻量级进程”但它的资源隔离更少所以创建和切换成本更低。2. 进程状态机五状态、七状态还是更复杂的图2.1 经典五状态模型操作系统教材的“标准答案”进程从创建到销毁到底会经历哪些状态绝大多数教材给的是五状态模型新建态New→就绪态Ready→运行态Running→阻塞态Blocked/Waiting→终止态Terminated外加两条“虚线”动态就绪态和阻塞态都可以直接回新建态不这里要注意新建态只会单向进入就绪态如果系统资源足够终止态是终点没有出口。我把这五个状态用大白话翻译一遍新建态进程正在被创建PCB已分配但还没就绪。比如你双击一个程序系统正在加载它的代码段和数据段到内存这时候进程还在“萌芽期”。就绪态进程万事俱备只欠CPU。它已经在内存里了数据已经加载好了随时可以上CPU执行但CPU这会儿正在忙别的进程所以它只能排队等。运行态进程真正在CPU上执行指令。在一个单核CPU上同一时刻只能有一个进程处于运行态多核CPU则可以有多个。阻塞态进程在运行过程中主动或被动地等待某个事件发生。比如等待用户输入、等待磁盘I/O完成、等待网络数据包到达。这期间它就算拿到了CPU也无法继续执行所以干脆让出CPU去“睡觉”。终止态进程已经结束执行正常退出或被杀死但PCB可能还没立刻被操作系统回收还需要等待父进程“收尸”或系统做最后的清理工作。2.2 状态之间的转换谁允许、谁不允许状态转换是考试和面试最喜欢出题的地方。我把允许的转换和不允许的转换整理成一个速查表转换方向触发条件允许吗新建 → 就绪就绪进程创建完毕进入内存就绪队列允许就绪 → 运行运行调度器选中该进程分配CPU允许运行 → 就绪让出时间片用完或被更高优先级进程抢占允许运行 → 阻塞等待进程发起I/O请求或等待某事件允许阻塞 → 就绪唤醒等待的事件发生如I/O完成、信号到达允许运行 → 终止结束执行完毕或被强制终止允许阻塞 → 运行直接上CPU——禁止必须先回就绪态就绪 → 阻塞直接等待——禁止就绪态不能主动发起等待最后一个“就绪 → 阻塞”为什么禁止因为就绪态意味着进程还没上CPU呢它没在执行指令拿什么去发起I/O请求它连“请求”这个动作都还没做怎么就能去“等待”呢所以这个转换在逻辑上就是荒谬的。同理阻塞态不能直接回到运行态因为阻塞态下的进程连CPU都没用上被唤醒后必须走一遍就绪队列等调度器重新分配CPU。这两条“禁止转换”看起来很简单但很多人画状态图的时候会手滑连错考试的时候也经常考这个点。我的记法很简单“阻塞转就绪、就绪转运行、运行转三态”——运行态能转去就绪、阻塞、终止三个方向其他状态都在“就绪”这个中转站里换乘。2.3 五状态不够用的时候为什么要引入挂起七状态模型五状态模型已经能描述绝大多数场景但它有一个盲区进程在内存里等着但内存不够了怎么办想象一下你电脑内存8G开了很多程序每个进程都在就绪队列或者阻塞队列里待着占用内存。如果这时候你又要启动一个需要2G内存的大软件内存不够了。操作系统怎么办它可以选择把某些“不重要”的进程挂起来也就是把它们的整个地址空间换出swap out到磁盘的交换分区里腾出内存给新进程用。这就是**挂起态Suspended**的由来。挂起态又分为两种就绪挂起Ready Suspended进程在内存中是就绪的被挂起后换出到磁盘但它还是“就绪”的只是暂时没法上CPU。阻塞挂起Blocked Suspended进程原来在阻塞态等待事件被挂起后换出到磁盘。它等待的事件发生之后会先转成“就绪挂起”需要操作系统把它换入内存再进入普通就绪队列。引入挂起之后状态图就变成了七状态模型有的教材画九状态多两个“新建挂起”和“终止挂起”核心逻辑一样。实际考试中以五状态为主但七状态是理解“内存紧张时系统怎么办”的关键。我做过一个Linux实验验证这个现象用free命令看内存快满了然后用cat /proc/meminfo | grep Swap观察交换分区的使用量再把一个空闲进程用CtrlZ挂起SIGTSTP你会在ps里看到它的状态变成Tstopped这就是挂起态的一个具体体现。不过Linux下的T状态和操作系统的“挂起态”不完全一致这个我在3.4节会专门讲避免你踩坑。3. 进程状态管理的核心机制调度、切换和队列3.1 状态在哪里被记录调度器的工作台现在我们知道了进程有那么多状态那操作系统到底是怎么“管理”这些状态的答案是队列Queue。操作系统会维护若干核心队列比如就绪队列保存所有处于就绪态的进程。调度器每次要选下一个进程上CPU的时候就是从这个队列里挑一个选谁取决于调度算法比如时间片轮转、优先级调度、多级反馈队列等。阻塞队列保存所有处于阻塞态的进程。这里又常常按等待的原因细分比如“等待磁盘I/O队列”、“等待键盘输入队列”、“等待网卡数据队列”这样唤醒的时候能精确地找到要唤醒的那一批进程。运行队列在单核CPU上就绪队列和运行队列可以理解为“排队等候区”和“正在台上表演的人”。进程被选中后就从就绪队列摘出来变成“运行中”等它主动阻塞、时间片用完或者被抢占再回到对应的队列。这套队列机制就是进程管理的骨架。你可以把调度器想象成餐厅的领位员顾客进程在候餐区就绪队列等着领位员按照一定的策略安排谁入座上CPU入座后如果顾客要等菜I/O就先离席去等候区阻塞队列菜好了再叫号回来重新排队。3.2 进程切换上下文切换不是“分分钟”的事在讲状态转换的时候有一个最容易被初学者忽略、但实际最影响系统性能的概念——上下文切换Context Switch。当一个进程从运行态变成就绪态或阻塞态另一个进程从就绪态变成运行态时操作系统必须做一件事把当前进程的“现场”保存起来再把新进程的“现场”恢复出来。“现场”包括什么主要是CPU寄存器的值通用寄存器、程序计数器PC、状态寄存器等进程的内存管理信息页表基址等浮点寄存器状态这个过程在操作系统课程里叫“保存现场、恢复现场”是整个进程状态转换里最核心的底层操作。它的开销有多大一次上下文切换大概需要消耗几个微秒看起来很短但如果系统里有几百个进程调度器每一秒钟要进行几十上百次切换累积起来就是明显的CPU开销。有一个学习技巧我很推荐用vmstat命令查看Linux系统的上下文切换次数vmstat 1 10你会看到cscontext switch那一列数值如果一直很高比如几万次每秒说明系统在“疯狂”切换进程。如果再配合top看CPU的%waI/O等待高不高就能初步判断系统是不是在某个环节卡住了。这里我想提醒一点上下文切换不是越少越好也不是越多越坏。如果切换太频繁CPU都在“换人”没在“干活”系统吞吐量反而下降如果切换太少某个进程霸占CPU太长时间交互性就差比如打字都卡。所以调度器要在这两个极端之间找平衡这也是后面“调度算法”那一章的核心矛盾。3.3 状态管理要解决的三大问题互斥、同步、死锁进程状态管理不只是“画状态图、做队列”它还牵扯到多个进程之间“抢资源”的问题。操作系统课的进程管理章节通常紧接着就会讲三大经典问题我这里稍微串一下方便你把知识连成网临界区与互斥多个进程访问同一份共享数据比如打印机队列、共享计数器必须有某种机制保证同一时刻只有一个进程在“临界区”里操作否则就会数据错乱。进程同步两个进程之间可能需要按顺序执行。比如“生产者-消费者问题”生产者没生产消费者就别去消费这需要信号量或条件变量来实现。死锁进程A占了资源1想等资源2进程B占了资源2想等资源1谁都不退让就死锁了。操作系统课程里讲死锁的四个必要条件互斥、占有且等待、不可剥夺、循环等待就是为了让你能识别和避免这种情况。这三个问题和进程状态的关系在哪里很简单进程在等待共享资源的时候就会进入阻塞态。如果这个互相等待形成了环就会导致一批进程全部卡在阻塞态谁也动不了。你在用top看到一堆进程状态都是D不可中断睡眠的时候就要小心是不是有资源争抢导致的异常。写成代码就是常见的多线程死锁——线程A锁着资源1等资源2线程B锁着资源2等资源1程序直接“卡死”。3.4 Linux系统中进程状态的实际含义别被教材骗了教材上的“就绪、运行、阻塞”和你在Linux里用命令看到的进程状态是一一对应的吗答案是但不完全是。我直接给你一张Linux下的进程状态速查表这是实操中真的能用上的东西Linux状态码内核中的状态对应教材概念你能看到的场景RTASK_RUNNING运行态或就绪态正在用CPU或在就绪队列里排队的进程STASK_INTERRUPTIBLE阻塞态可中断等待事件但可以被信号唤醒比如普通的sleepDTASK_UNINTERRUPTIBLE阻塞态不可中断正在等待磁盘I/O等不能被信号打断杀不掉的进程经常是这个状态TTASK_STOPPED挂起态暂停被CtrlZ或SIGSTOP暂停的进程tTASK_TRACING_STOPPED挂起态跟踪暂停正在被gdb调试的进程ZTASK_DEAD/EXIT_ZOMBIE终止态僵尸子进程结束了但没被父进程回收变成“僵尸”XTASK_DEAD/EXIT_DEAD终止态死亡进程彻底结束这里最值得注意的两个坑第一个坑R状态不等于“正在运行”。在单核CPU上R状态的进程可能有几十个但真正在CPU上执行的只有一个。其余的都是“就绪态”只是还没轮到。所以top里看到%CPU很低但R很多说明系统负载高但CPU利用率还没饱和。第二个坑D状态不可中断睡眠是著名的“杀不死”状态。教材上说的阻塞态通常是Sinterruptible sleep这种进程会被信号唤醒比如你用kill发一个SIGTERM能把它终止。但D状态的进程正在做底层I/O内核不希望你在这个过程中打断它所以连SIGKILL对它都无效。你真的遇到过kill -9杀不掉进程的情况吗大概率就是它处在D状态等它I/O完成之后才会自动消失。这个知识点在实际排查线上问题的时候极其重要。4. 实操自己动手创建一个进程、观察它的状态、把它“玩坏”4.1 从C代码到进程写一个会“变状态”的程序理论知识先放一放我们来写一段C语言代码然后通过它把进程状态变化“看”出来。这里用Linux环境你需要一个gcc编译器和bash终端。#include stdio.h #include unistd.h #include sys/wait.h int main() { pid_t pid fork(); // fork() 创建子进程 if (pid 0) { perror(fork failed); return 1; } else if (pid 0) { // 子进程代码 printf([子进程] 我被创建了我的PID是 %d\n, getpid()); printf([子进程] 我准备休眠5秒\n); sleep(5); // 进入睡眠态S printf([子进程] 睡醒了准备退出\n); return 42; // 退出码42 } else { // 父进程代码 printf([父进程] 我创建了子进程它的PID是 %d\n, pid); printf([父进程] 我现在等着回收子进程\n); int status; wait(status); // 父进程阻塞等待子进程结束 printf([父进程] 子进程退出了退出码相关%d\n, WEXITSTATUS(status)); } return 0; }编译并运行gcc -o procdemo procdemo.c ./procdemo 我们在运行程序时加上让它在后台运行。然后开另一个终端用ps观察进程状态ps -o pid,ppid,state,cmd -C procdemo你会看到类似这样的输出PID PPID S CMD 1234 1000 S ./procdemo 1235 1234 S ./procdemo两个进程都处于S状态因为父进程在wait()阻塞等待子进程在sleep()。如果去掉sleep(5)改成while(1);死循环子进程的状态就会变成R因为它在不停占用CPU。这个小实验的意义在于你亲手制造了进程的状态转换并且亲眼看到了教材上的“阻塞态”在真实系统里长什么样。4.2ps、top、vmstat三个命令组合起来看进程“心电图”我自己最喜欢的进程状态观察组合是这三个命令搭配使用ps瞬间快照看当前有哪些进程、什么状态。ps -eLf # 显示线程级别的进程状态 ps aux # 显示CPU和内存占用 ps -eo pid,stat,comm --sort-pid # 按PID倒序看当前进程和状态top动态刷新看实时CPU、内存、进程状态分布。top -d 1 # 每秒刷新一次top顶部有个%Cpu(s)行后面us、sy、wa、st这些字段的信息waiowait如果高说明进程在大量等待磁盘I/O——对应到下标就是一批D状态进程。vmstat看系统整体的进程队列和上下文切换情况。vmstat 2rrunning/runnable列是就绪队列长度bblocked列是阻塞进程数cs列是上下文切换次数。这三个数值配合起来能快速判断系统是不是“活得很累”。4.3 实战制造一个“僵尸进程”并回收它僵尸进程Zombie是进程状态里最出名的一个“怪物”。它的产生原因很简单子进程先结束了但父进程还没用wait()把它回收。这时候子进程的PCB还没被完全清理它就在系统里“诈尸”。下面这段代码能让父进程故意不回收子进程然后我们观察僵尸状态的出现#include stdio.h #include unistd.h int main() { pid_t pid fork(); if (pid 0) { // 子进程立即退出 printf([子进程] 我先走一步\n); return 0; } else { // 父进程睡眠10秒不给子进程“收尸” printf([父进程] 我故意不wait让子进程变僵尸\n); sleep(10); printf([父进程] 睡完了父进程退出\n); } return 0; }运行之后马上在另一个终端执行ps -eo pid,stat,ppid,comm | grep zombie_demo你会看到一个状态为Z的进程它的PPID指向父进程。等父进程sleep(10)结束后退出这个僵尸进程的PPID会变成1init/systemd接管如果init进程不及时回收它可能还会在系统里多待一会儿。这里有个常见误解很多人以为僵尸进程会一直占CPU、占内存其实僵尸进程的代码和执行资源已经释放了只剩下一个PCB结构占用的内存极小。但它的问题在于如果你写了一个父进程循环创建子进程又从来不wait()那么僵尸PCB会越积越多最终把PID号耗尽导致新进程无法创建。这个在长时间运行的服务器程序里是真实踩过的大坑。我自己的排查教训是看到Z状态的进程不是急着kill -9它杀不掉因为它已经死了只是没被“收尸”而是要找到它的父进程正确的方法是让父进程调用wait()或waitpid()回收或者干脆把父进程退出让init进程来领养。4.4 操作怎么优雅地控制进程状态kill命令是我们在终端里控制进程状态最常用的手段。但它不只是“杀进程”的意思更准确的翻译是“向进程发送信号”。信号是Linux进程管理里非常重要的通信机制。信号编号默认动作实际场景SIGTERM15终止进程kill pid默认发这个进程可以捕获并做清理后退出SIGKILL9强制杀死kill -9 pid不可被捕获/忽略。D状态的进程也杀不掉SIGSTOP19暂停进程相当于进程被“冻结”kill -STOP pidSIGCONT18继续运行让暂停的进程继续kill -CONT pidSIGHUP1挂断控制终端终端断开时给前台进程组发送常用来让进程重读配置SIGINT2中断进程你在终端按CtrlC就是发这个用一个实际场景串起来程序卡死了你该怎么处理先用ps或htop找到目标进程的PID和状态。先发SIGTERM默认kill pid让它自己清理退出。等几秒没反应再发SIGKILLkill -9 pid。如果连SIGKILL都杀不掉看它的状态是不是D——如果是等I/O完成或者检查存储系统如果不是说明它陷入内核态无法响应这时候可能需要重启或者检查驱动。这个流程我几乎天天在用它是每个程序员都该有的肌肉记忆。踩坑提醒不要一上来就kill -9很多程序在退出时需要保存状态、写日志、释放锁强行SIGKILL会让数据处于不一致状态。比如MySQL、Redis这类数据库如果经常被kill -9很可能造成数据文件损坏。5. 进阶状态管理在并发和死锁中的实际表现5.1 状态转换与锁为什么多线程程序会“卡死”写多线程代码的时候最常遇到的线上问题就是“程序卡住不动了”。从进程状态的角度看程序卡住的本质是线程在等待一个永远不会被释放的锁从运行态进入了阻塞态然后永远回不到就绪态。我用Java来演示一个经典死锁场景因为这个例子我在工作中排查过很多次public class DeadlockDemo { private static final Object resourceA new Object(); private static final Object resourceB new Object(); public static void main(String[] args) { Thread t1 new Thread(() - { synchronized (resourceA) { System.out.println(线程1持有了资源A); try { Thread.sleep(100); } catch (InterruptedException e) {} System.out.println(线程1等待资源B...); synchronized (resourceB) { System.out.println(线程1拿到了资源B); } } }); Thread t2 new Thread(() - { synchronized (resourceB) { System.out.println(线程2持有了资源B); try { Thread.sleep(100); } catch (InterruptedException e) {} System.out.println(线程2等待资源A...); synchronized (resourceA) { System.out.println(线程2拿到了资源A); } } }); t1.start(); t2.start(); } }这段代码只要跑起来大概率在控制台输出两条“等待”信息之后就永久卡死。因为线程1拿着A等B线程2拿着B等A互相不让步。怎么从进程状态的角度去观察它用jps找到Java进程PID再用jstack打印线程堆栈jps -l jstack pidjstack会输出类似这样的关键段落Thread-0 - Thread t... java.lang.Thread.State: BLOCKED (on object monitor) - waiting to lock 0x00000000d5e7c3a8 (a java.lang.Object) - locked 0x00000000d5e7c390 (a java.lang.Object)两个线程都是BLOCKED状态互相等待对方持有的锁——这就是死锁的实锤。所以你在操作系统里学的进程阻塞态在Java线程层面就是BLOCKED状态两者概念是相通的。5.2 状态管理的终极目标让资源利用率、响应时间和公平性达成平衡学到这里你可能会问搞这么多状态管理到底图什么操作系统管理进程追求的目标无非是三个资源利用率CPU、内存、磁盘这些硬件资源尽量别闲着。如果就绪队列里永远有进程等着CPU就一直在干活利用率就高。响应时间用户点击、键盘输入要尽快有回馈。如果调度器让一个后台计算任务霸占CPU 10秒钟你在终端打字就会卡这叫响应时间差。吞吐量单位时间内系统能完成的作业数量。有时候为了吞吐量是可以适当牺牲响应时间的。这三个目标是有矛盾的。比如时间片轮转调度算法把CPU时间切得很碎每个进程轮流用很短的时间响应时间很好但上下文切换开销大CPU利用率受到一定影响。而先来先服务算法实现简单、切换开销小但一个长任务会阻塞后续所有任务响应时间极差。操作系统课程后面会逐一介绍各种调度算法先来先服务FCFS、短作业优先SJF、高响应比优先HRRN、时间片轮转RR、多级反馈队列MFQ等。每学一个算法你都应该回到“进程状态转换”的视角来理解这个算法是从就绪队列里按什么规则挑进程挑出来之后是让它一直运行到阻塞还是运行固定时间片被抢占的进程回到就绪队列的队尾还是队首把这些想明白调度算法就不再是死记硬背而是一套有逻辑的方案集合。5.3 从进程到线程再到协程状态管理的层次演进现代操作系统课程还会涉及一个议题既然进程切换那么贵能不能让它更轻量于是有了线程线程共享进程的地址空间和资源上下文切换成本比进程低得多。再往后有了协程比如Go的goroutine、Python的asyncio连内核态的调度都省了改由用户态自己管理。站在状态管理的角度看这个演进你会发现一件事无论底层还是上层核心思想都是一样的——把“等待”这件事情从阻塞变成挂起、把“切换”变得越来越便宜。在进程层面等待I/O会进入阻塞态由内核调度器管理。在线程层面线程间的同步等待由线程库管理但最终挂起还是牵涉到内核线程调度。在协程层面用户态程序自己保存和恢复执行上下文等待I/O的时候协程主动yield出执行权而不是把自己交给内核所以切换成本极低可以实现十万甚至百万级别的并发。我曾经用Go写过一个高并发服务一开始对goroutine的调度充满好奇它怎么做到一个进程几百万协程的后来去读了一点Go runtime的源码才发现它的调度器本质上就是一个用户态的“就绪队列运行队列”协程在被channel阻塞时会把自己挂到等待队列事件到达后重新放回就绪队列。这套机制和操作系统内核的进程队列思想一模一样只不过实现精细到了用户态。我在实际调优的时候用GODEBUGschedtrace1000跑过一次看到runqueue运行队列长度和waiting等待协程数的变化才算真正把操作系统课程里的队列模型融会贯通了。6. 常见问题与排查技巧实录这部分是我在实际学习和工作里反复踩坑攒下来的经验整理成速查表希望能帮你避开同样的坑。6.1 常见问题速查表问题现象可能原因排查命令 / 处理方式kill -9杀不掉进程进程处于D不可中断睡眠状态等待其I/O完成检查磁盘/网络存储是否有故障系统出现大量Z状态进程父进程没有调用wait()回收子进程定位父进程PID修复代码或重启父进程top显示CPU高但响应慢进程频繁上下文切换或大量进程争抢锁vmstat看cspidstat -w看线程切换必要时调整线程数程序卡死CPU为0%死锁或线程阻塞在等待事件jstackJava、gdbattachC看堆栈系统负载高但CPU利用率低大量D状态进程等待I/Oiostat -x 1查看磁盘I/O确认是否有IO瓶颈一个进程用完所有CPU核心多线程程序没有正确同步线程都在自旋top -H查看线程级CPU占用定位热点线程6.2 排查线上问题的一个经典思路当线上服务卡顿或者CPU异常的时候我按下面这个顺序排查第一步top -H -p pid先看某个进程内部的线程CPU分布。如果只有一个线程CPU跑到100%多半是某个热点功能在死循环或疯狂计算如果线程全都因为等待不到资源而CPU很低那可能是死锁或者锁竞争。第二步vmstat 1看看系统整体的上下文切换数量和阻塞进程数。cs如果上万说明系统在大量切换线程很可能线程池开太大了。第三步用语言的线程转储工具抓当前状态。Java用jstackGo用Ctrl\SIGQUIT打印协程栈C/C用gdb attach。这一步能把卡住的线程现场直接暴露出来。第四步如果你的服务是Docker容器记得在宿主机上看进程状态因为容器内看到的进程就是宿主机的进程。用ps -eo pid,stat,cmd过滤出容器进程可以看到其真实状态。6.3 学习建议怎么把进程状态这块学扎实最后分享一点学习方法上的体会。操作系统这门课纯看书很容易“看懂了但不会用”尤其是进程状态这块光背状态图不如亲手去跑几个实验来得扎实。我的建议是三件事第一写一个带fork()和wait()的小程序亲手创建和管理子进程观察不同阶段的进程状态。这个实验在现代Linux课程或实验室里都很容易复现不需要什么高大上的环境一个gcc终端就够。第二结合具体的多线程框架去验证概念。比如你写Java就去看Thread.State的六种枚举值NEW、RUNNABLE、BLOCKED、WAITING、TIMED_WAITING、TERMINATED和操作系统进程状态的对照。写Go就去看goroutine的runnable、running、waiting状态。你会发现操作系统课程里的“就绪、运行、阻塞”只是不同语言的命名差异。第三把排障命令练成肌肉记忆。ps、top、vmstat、pidstat、kill、jstack这套工具链要滚瓜烂熟。我见过很多人看完操作系统理论能考高分但真到线上服务卡死的时候连ps看状态都不会用这就是理论和实践脱节。操作系统这门课用来应付考试的部分可能一个月就学完了但真正内化成排查问题的直觉需要在实际项目里反复磨。根据我个人经验进程状态是操作系统的“地基”地基稳了后面学内存管理、文件系统、I/O子系统才不至于越学越懵。每次遇到“进程为什么卡”、“资源被谁占了”、“怎么杀掉这个进程”这类问题先回到状态模型上推一遍大概率能找到答案。最后再分享一个小技巧如果你在Linux里想快速看当前系统进程状态的分布可以用这一行命令把所有进程的状态统计出来ps -eo stat | awk {print $1} | sort | uniq -c输出结果会类似3 R 12 S 1 Z这样几个数字一对比你一眼就知道系统到底是在正常轮转、I/O等待还是出现了僵尸泄漏。这就是把状态管理知识用到了点子上。
深度解析进程状态：从五状态模型到Linux实战排查
开篇从“一个程序无法同时干两件事”说起你有没有想过你在浏览器里刷网页的同时后台的播放器在放歌微信在接收消息杀毒软件在扫描磁盘——这些都是同时发生的。但你的CPU一共就那么多核它怎么做到“一心多用”的答案是操作系统用一种非常聪明的机制在**“骗”你它让每个程序轮流占用CPU切换得足够快快到你以为它们是并行跑在同一个核心上的。而这个机制的核心就是进程**。进程是操作系统里最重要的抽象概念之一也是任何一门《操作系统》课程无论如何都绕不开的章节。很多初学者刚开始接触“进程状态”的时候会觉得状态图就那么几个圈、几条线背一背就能过考试。但实际一做实验、一写多线程代码就发现不对劲了为什么程序卡住了为什么明明有多个进程却跑不满CPU为什么kill杀不掉某个进程这背后全是对进程状态与管理的理解不够深入。这篇文章就是我的操作系统学习笔记整理既包含课程核心知识点的拆解也会把我在实验和项目里踩过的坑、用过的排查命令、真正有效的学习方法写出来。内容适合正在学操作系统的大学生、准备考研408计算机统考的同学以及工作中想真正搞懂进程管理、排查线上问题的程序员。通篇不讲废话直接上干货。1. 进程到底是个什么东西从程序到进程的“质变”1.1 程序是死的进程是活的先打一个非常生活化的比方。程序文件比如你下载的wechat.exe就像一张菜谱它躺在硬盘上是静态的不会自己动。而进程就像一位厨师正在照着菜谱做菜——他占用了厨房内存、拿着厨具CPU寄存器、正在处理食材数据每一步都有实实在在的状态。操作系统管理的不再是“菜谱”而是“厨师”的整个工作状态。所以进程是程序的一次执行过程是系统进行资源分配和调度的基本单位。这句话是教材里的标准定义但它有几个关键细节值得拆开说“一次执行过程”意味着同一个程序可以被启动多次产生多个不同的进程。比如你开了三个终端窗口每个窗口都在运行vim那就有三个vim进程它们彼此独立互不干扰。“资源分配”指的是每个进程都有自己独立的地址空间、打开的文件描述符、环境变量、工作目录等。进程之间默认是相互隔离的一个进程崩溃了不会直接导致另一个进程崩溃。“调度”指的是CPU资源是怎么分配给多个进程使用的。谁先用、用多久、什么时候被换下去这些都由操作系统的调度器决定。理解了这几点你就能明白为什么说进程是操作系统的核心——文件管理、内存管理、设备管理最终都要服务于“让这些进程能好好运行”这件事。1.2 认识进程的“身份证”PCB每个进程在操作系统内部都有一个对应的数据结构来记录它的全部信息这个结构就是PCB进程控制块Process Control Block。你可以把它理解为进程的“病历本”或者“身份证档案”。PCB里到底装了什么我把它分成四类信息方便记忆信息类别具体内容作用进程标识符PID、父进程PPID、用户ID等唯一区分每个进程处理机状态通用寄存器值、程序计数器PC、状态字等保存进程被换下CPU时的现场下次换上来能接着跑进程调度信息进程状态、优先级、等待原因等调度器根据这些信息决定谁上CPU进程控制信息内存边界、打开的文件列表、I/O设备列表等管理和回收进程资源这里最重要的一个知识点是PCB是进程存在的唯一标志。也就是说一个进程从被创建开始操作系统为它建立一个PCB进程结束时操作系统收回PCB。你哪怕看不到进程在跑什么代码只要PCB还在这个进程就算存在。这个机制也解释了操作系统的经典面试题“操作系统是怎么知道某个内存地址属于哪个进程的”“进程崩溃了为什么其他进程不受影响”答案都指向PCB——系统通过PCB来管理进程所拥有的全部资源进程间的隔离就是靠这套独立的PCB资源记录实现的。1.3 进程和线程先分清这两个概念很多教材会把进程和线程放在一起讲很多初学者也容易混。我的理解是这样的进程是资源分配的单位线程是CPU调度的单位。一个进程内部可以包含多个线程这些线程共享进程的地址空间和资源比如内存、文件句柄但每个线程有自己的栈和寄存器上下文。你可以把进程想象成一家公司线程就是公司里的员工。公司拥有办公场地和设备资源员工负责具体干活占用CPU。员工之间共享公司的资源但每个员工的工作状态是独立的。这个区分在学习进程状态的时候尤其重要。因为你后面会看到Linux里的top命令显示的线程状态、Java里Thread.State的枚举值都和操作系统的进程状态密切相关。站在操作系统层面线程本质上也是一种“轻量级进程”但它的资源隔离更少所以创建和切换成本更低。2. 进程状态机五状态、七状态还是更复杂的图2.1 经典五状态模型操作系统教材的“标准答案”进程从创建到销毁到底会经历哪些状态绝大多数教材给的是五状态模型新建态New→就绪态Ready→运行态Running→阻塞态Blocked/Waiting→终止态Terminated外加两条“虚线”动态就绪态和阻塞态都可以直接回新建态不这里要注意新建态只会单向进入就绪态如果系统资源足够终止态是终点没有出口。我把这五个状态用大白话翻译一遍新建态进程正在被创建PCB已分配但还没就绪。比如你双击一个程序系统正在加载它的代码段和数据段到内存这时候进程还在“萌芽期”。就绪态进程万事俱备只欠CPU。它已经在内存里了数据已经加载好了随时可以上CPU执行但CPU这会儿正在忙别的进程所以它只能排队等。运行态进程真正在CPU上执行指令。在一个单核CPU上同一时刻只能有一个进程处于运行态多核CPU则可以有多个。阻塞态进程在运行过程中主动或被动地等待某个事件发生。比如等待用户输入、等待磁盘I/O完成、等待网络数据包到达。这期间它就算拿到了CPU也无法继续执行所以干脆让出CPU去“睡觉”。终止态进程已经结束执行正常退出或被杀死但PCB可能还没立刻被操作系统回收还需要等待父进程“收尸”或系统做最后的清理工作。2.2 状态之间的转换谁允许、谁不允许状态转换是考试和面试最喜欢出题的地方。我把允许的转换和不允许的转换整理成一个速查表转换方向触发条件允许吗新建 → 就绪就绪进程创建完毕进入内存就绪队列允许就绪 → 运行运行调度器选中该进程分配CPU允许运行 → 就绪让出时间片用完或被更高优先级进程抢占允许运行 → 阻塞等待进程发起I/O请求或等待某事件允许阻塞 → 就绪唤醒等待的事件发生如I/O完成、信号到达允许运行 → 终止结束执行完毕或被强制终止允许阻塞 → 运行直接上CPU——禁止必须先回就绪态就绪 → 阻塞直接等待——禁止就绪态不能主动发起等待最后一个“就绪 → 阻塞”为什么禁止因为就绪态意味着进程还没上CPU呢它没在执行指令拿什么去发起I/O请求它连“请求”这个动作都还没做怎么就能去“等待”呢所以这个转换在逻辑上就是荒谬的。同理阻塞态不能直接回到运行态因为阻塞态下的进程连CPU都没用上被唤醒后必须走一遍就绪队列等调度器重新分配CPU。这两条“禁止转换”看起来很简单但很多人画状态图的时候会手滑连错考试的时候也经常考这个点。我的记法很简单“阻塞转就绪、就绪转运行、运行转三态”——运行态能转去就绪、阻塞、终止三个方向其他状态都在“就绪”这个中转站里换乘。2.3 五状态不够用的时候为什么要引入挂起七状态模型五状态模型已经能描述绝大多数场景但它有一个盲区进程在内存里等着但内存不够了怎么办想象一下你电脑内存8G开了很多程序每个进程都在就绪队列或者阻塞队列里待着占用内存。如果这时候你又要启动一个需要2G内存的大软件内存不够了。操作系统怎么办它可以选择把某些“不重要”的进程挂起来也就是把它们的整个地址空间换出swap out到磁盘的交换分区里腾出内存给新进程用。这就是**挂起态Suspended**的由来。挂起态又分为两种就绪挂起Ready Suspended进程在内存中是就绪的被挂起后换出到磁盘但它还是“就绪”的只是暂时没法上CPU。阻塞挂起Blocked Suspended进程原来在阻塞态等待事件被挂起后换出到磁盘。它等待的事件发生之后会先转成“就绪挂起”需要操作系统把它换入内存再进入普通就绪队列。引入挂起之后状态图就变成了七状态模型有的教材画九状态多两个“新建挂起”和“终止挂起”核心逻辑一样。实际考试中以五状态为主但七状态是理解“内存紧张时系统怎么办”的关键。我做过一个Linux实验验证这个现象用free命令看内存快满了然后用cat /proc/meminfo | grep Swap观察交换分区的使用量再把一个空闲进程用CtrlZ挂起SIGTSTP你会在ps里看到它的状态变成Tstopped这就是挂起态的一个具体体现。不过Linux下的T状态和操作系统的“挂起态”不完全一致这个我在3.4节会专门讲避免你踩坑。3. 进程状态管理的核心机制调度、切换和队列3.1 状态在哪里被记录调度器的工作台现在我们知道了进程有那么多状态那操作系统到底是怎么“管理”这些状态的答案是队列Queue。操作系统会维护若干核心队列比如就绪队列保存所有处于就绪态的进程。调度器每次要选下一个进程上CPU的时候就是从这个队列里挑一个选谁取决于调度算法比如时间片轮转、优先级调度、多级反馈队列等。阻塞队列保存所有处于阻塞态的进程。这里又常常按等待的原因细分比如“等待磁盘I/O队列”、“等待键盘输入队列”、“等待网卡数据队列”这样唤醒的时候能精确地找到要唤醒的那一批进程。运行队列在单核CPU上就绪队列和运行队列可以理解为“排队等候区”和“正在台上表演的人”。进程被选中后就从就绪队列摘出来变成“运行中”等它主动阻塞、时间片用完或者被抢占再回到对应的队列。这套队列机制就是进程管理的骨架。你可以把调度器想象成餐厅的领位员顾客进程在候餐区就绪队列等着领位员按照一定的策略安排谁入座上CPU入座后如果顾客要等菜I/O就先离席去等候区阻塞队列菜好了再叫号回来重新排队。3.2 进程切换上下文切换不是“分分钟”的事在讲状态转换的时候有一个最容易被初学者忽略、但实际最影响系统性能的概念——上下文切换Context Switch。当一个进程从运行态变成就绪态或阻塞态另一个进程从就绪态变成运行态时操作系统必须做一件事把当前进程的“现场”保存起来再把新进程的“现场”恢复出来。“现场”包括什么主要是CPU寄存器的值通用寄存器、程序计数器PC、状态寄存器等进程的内存管理信息页表基址等浮点寄存器状态这个过程在操作系统课程里叫“保存现场、恢复现场”是整个进程状态转换里最核心的底层操作。它的开销有多大一次上下文切换大概需要消耗几个微秒看起来很短但如果系统里有几百个进程调度器每一秒钟要进行几十上百次切换累积起来就是明显的CPU开销。有一个学习技巧我很推荐用vmstat命令查看Linux系统的上下文切换次数vmstat 1 10你会看到cscontext switch那一列数值如果一直很高比如几万次每秒说明系统在“疯狂”切换进程。如果再配合top看CPU的%waI/O等待高不高就能初步判断系统是不是在某个环节卡住了。这里我想提醒一点上下文切换不是越少越好也不是越多越坏。如果切换太频繁CPU都在“换人”没在“干活”系统吞吐量反而下降如果切换太少某个进程霸占CPU太长时间交互性就差比如打字都卡。所以调度器要在这两个极端之间找平衡这也是后面“调度算法”那一章的核心矛盾。3.3 状态管理要解决的三大问题互斥、同步、死锁进程状态管理不只是“画状态图、做队列”它还牵扯到多个进程之间“抢资源”的问题。操作系统课的进程管理章节通常紧接着就会讲三大经典问题我这里稍微串一下方便你把知识连成网临界区与互斥多个进程访问同一份共享数据比如打印机队列、共享计数器必须有某种机制保证同一时刻只有一个进程在“临界区”里操作否则就会数据错乱。进程同步两个进程之间可能需要按顺序执行。比如“生产者-消费者问题”生产者没生产消费者就别去消费这需要信号量或条件变量来实现。死锁进程A占了资源1想等资源2进程B占了资源2想等资源1谁都不退让就死锁了。操作系统课程里讲死锁的四个必要条件互斥、占有且等待、不可剥夺、循环等待就是为了让你能识别和避免这种情况。这三个问题和进程状态的关系在哪里很简单进程在等待共享资源的时候就会进入阻塞态。如果这个互相等待形成了环就会导致一批进程全部卡在阻塞态谁也动不了。你在用top看到一堆进程状态都是D不可中断睡眠的时候就要小心是不是有资源争抢导致的异常。写成代码就是常见的多线程死锁——线程A锁着资源1等资源2线程B锁着资源2等资源1程序直接“卡死”。3.4 Linux系统中进程状态的实际含义别被教材骗了教材上的“就绪、运行、阻塞”和你在Linux里用命令看到的进程状态是一一对应的吗答案是但不完全是。我直接给你一张Linux下的进程状态速查表这是实操中真的能用上的东西Linux状态码内核中的状态对应教材概念你能看到的场景RTASK_RUNNING运行态或就绪态正在用CPU或在就绪队列里排队的进程STASK_INTERRUPTIBLE阻塞态可中断等待事件但可以被信号唤醒比如普通的sleepDTASK_UNINTERRUPTIBLE阻塞态不可中断正在等待磁盘I/O等不能被信号打断杀不掉的进程经常是这个状态TTASK_STOPPED挂起态暂停被CtrlZ或SIGSTOP暂停的进程tTASK_TRACING_STOPPED挂起态跟踪暂停正在被gdb调试的进程ZTASK_DEAD/EXIT_ZOMBIE终止态僵尸子进程结束了但没被父进程回收变成“僵尸”XTASK_DEAD/EXIT_DEAD终止态死亡进程彻底结束这里最值得注意的两个坑第一个坑R状态不等于“正在运行”。在单核CPU上R状态的进程可能有几十个但真正在CPU上执行的只有一个。其余的都是“就绪态”只是还没轮到。所以top里看到%CPU很低但R很多说明系统负载高但CPU利用率还没饱和。第二个坑D状态不可中断睡眠是著名的“杀不死”状态。教材上说的阻塞态通常是Sinterruptible sleep这种进程会被信号唤醒比如你用kill发一个SIGTERM能把它终止。但D状态的进程正在做底层I/O内核不希望你在这个过程中打断它所以连SIGKILL对它都无效。你真的遇到过kill -9杀不掉进程的情况吗大概率就是它处在D状态等它I/O完成之后才会自动消失。这个知识点在实际排查线上问题的时候极其重要。4. 实操自己动手创建一个进程、观察它的状态、把它“玩坏”4.1 从C代码到进程写一个会“变状态”的程序理论知识先放一放我们来写一段C语言代码然后通过它把进程状态变化“看”出来。这里用Linux环境你需要一个gcc编译器和bash终端。#include stdio.h #include unistd.h #include sys/wait.h int main() { pid_t pid fork(); // fork() 创建子进程 if (pid 0) { perror(fork failed); return 1; } else if (pid 0) { // 子进程代码 printf([子进程] 我被创建了我的PID是 %d\n, getpid()); printf([子进程] 我准备休眠5秒\n); sleep(5); // 进入睡眠态S printf([子进程] 睡醒了准备退出\n); return 42; // 退出码42 } else { // 父进程代码 printf([父进程] 我创建了子进程它的PID是 %d\n, pid); printf([父进程] 我现在等着回收子进程\n); int status; wait(status); // 父进程阻塞等待子进程结束 printf([父进程] 子进程退出了退出码相关%d\n, WEXITSTATUS(status)); } return 0; }编译并运行gcc -o procdemo procdemo.c ./procdemo 我们在运行程序时加上让它在后台运行。然后开另一个终端用ps观察进程状态ps -o pid,ppid,state,cmd -C procdemo你会看到类似这样的输出PID PPID S CMD 1234 1000 S ./procdemo 1235 1234 S ./procdemo两个进程都处于S状态因为父进程在wait()阻塞等待子进程在sleep()。如果去掉sleep(5)改成while(1);死循环子进程的状态就会变成R因为它在不停占用CPU。这个小实验的意义在于你亲手制造了进程的状态转换并且亲眼看到了教材上的“阻塞态”在真实系统里长什么样。4.2ps、top、vmstat三个命令组合起来看进程“心电图”我自己最喜欢的进程状态观察组合是这三个命令搭配使用ps瞬间快照看当前有哪些进程、什么状态。ps -eLf # 显示线程级别的进程状态 ps aux # 显示CPU和内存占用 ps -eo pid,stat,comm --sort-pid # 按PID倒序看当前进程和状态top动态刷新看实时CPU、内存、进程状态分布。top -d 1 # 每秒刷新一次top顶部有个%Cpu(s)行后面us、sy、wa、st这些字段的信息waiowait如果高说明进程在大量等待磁盘I/O——对应到下标就是一批D状态进程。vmstat看系统整体的进程队列和上下文切换情况。vmstat 2rrunning/runnable列是就绪队列长度bblocked列是阻塞进程数cs列是上下文切换次数。这三个数值配合起来能快速判断系统是不是“活得很累”。4.3 实战制造一个“僵尸进程”并回收它僵尸进程Zombie是进程状态里最出名的一个“怪物”。它的产生原因很简单子进程先结束了但父进程还没用wait()把它回收。这时候子进程的PCB还没被完全清理它就在系统里“诈尸”。下面这段代码能让父进程故意不回收子进程然后我们观察僵尸状态的出现#include stdio.h #include unistd.h int main() { pid_t pid fork(); if (pid 0) { // 子进程立即退出 printf([子进程] 我先走一步\n); return 0; } else { // 父进程睡眠10秒不给子进程“收尸” printf([父进程] 我故意不wait让子进程变僵尸\n); sleep(10); printf([父进程] 睡完了父进程退出\n); } return 0; }运行之后马上在另一个终端执行ps -eo pid,stat,ppid,comm | grep zombie_demo你会看到一个状态为Z的进程它的PPID指向父进程。等父进程sleep(10)结束后退出这个僵尸进程的PPID会变成1init/systemd接管如果init进程不及时回收它可能还会在系统里多待一会儿。这里有个常见误解很多人以为僵尸进程会一直占CPU、占内存其实僵尸进程的代码和执行资源已经释放了只剩下一个PCB结构占用的内存极小。但它的问题在于如果你写了一个父进程循环创建子进程又从来不wait()那么僵尸PCB会越积越多最终把PID号耗尽导致新进程无法创建。这个在长时间运行的服务器程序里是真实踩过的大坑。我自己的排查教训是看到Z状态的进程不是急着kill -9它杀不掉因为它已经死了只是没被“收尸”而是要找到它的父进程正确的方法是让父进程调用wait()或waitpid()回收或者干脆把父进程退出让init进程来领养。4.4 操作怎么优雅地控制进程状态kill命令是我们在终端里控制进程状态最常用的手段。但它不只是“杀进程”的意思更准确的翻译是“向进程发送信号”。信号是Linux进程管理里非常重要的通信机制。信号编号默认动作实际场景SIGTERM15终止进程kill pid默认发这个进程可以捕获并做清理后退出SIGKILL9强制杀死kill -9 pid不可被捕获/忽略。D状态的进程也杀不掉SIGSTOP19暂停进程相当于进程被“冻结”kill -STOP pidSIGCONT18继续运行让暂停的进程继续kill -CONT pidSIGHUP1挂断控制终端终端断开时给前台进程组发送常用来让进程重读配置SIGINT2中断进程你在终端按CtrlC就是发这个用一个实际场景串起来程序卡死了你该怎么处理先用ps或htop找到目标进程的PID和状态。先发SIGTERM默认kill pid让它自己清理退出。等几秒没反应再发SIGKILLkill -9 pid。如果连SIGKILL都杀不掉看它的状态是不是D——如果是等I/O完成或者检查存储系统如果不是说明它陷入内核态无法响应这时候可能需要重启或者检查驱动。这个流程我几乎天天在用它是每个程序员都该有的肌肉记忆。踩坑提醒不要一上来就kill -9很多程序在退出时需要保存状态、写日志、释放锁强行SIGKILL会让数据处于不一致状态。比如MySQL、Redis这类数据库如果经常被kill -9很可能造成数据文件损坏。5. 进阶状态管理在并发和死锁中的实际表现5.1 状态转换与锁为什么多线程程序会“卡死”写多线程代码的时候最常遇到的线上问题就是“程序卡住不动了”。从进程状态的角度看程序卡住的本质是线程在等待一个永远不会被释放的锁从运行态进入了阻塞态然后永远回不到就绪态。我用Java来演示一个经典死锁场景因为这个例子我在工作中排查过很多次public class DeadlockDemo { private static final Object resourceA new Object(); private static final Object resourceB new Object(); public static void main(String[] args) { Thread t1 new Thread(() - { synchronized (resourceA) { System.out.println(线程1持有了资源A); try { Thread.sleep(100); } catch (InterruptedException e) {} System.out.println(线程1等待资源B...); synchronized (resourceB) { System.out.println(线程1拿到了资源B); } } }); Thread t2 new Thread(() - { synchronized (resourceB) { System.out.println(线程2持有了资源B); try { Thread.sleep(100); } catch (InterruptedException e) {} System.out.println(线程2等待资源A...); synchronized (resourceA) { System.out.println(线程2拿到了资源A); } } }); t1.start(); t2.start(); } }这段代码只要跑起来大概率在控制台输出两条“等待”信息之后就永久卡死。因为线程1拿着A等B线程2拿着B等A互相不让步。怎么从进程状态的角度去观察它用jps找到Java进程PID再用jstack打印线程堆栈jps -l jstack pidjstack会输出类似这样的关键段落Thread-0 - Thread t... java.lang.Thread.State: BLOCKED (on object monitor) - waiting to lock 0x00000000d5e7c3a8 (a java.lang.Object) - locked 0x00000000d5e7c390 (a java.lang.Object)两个线程都是BLOCKED状态互相等待对方持有的锁——这就是死锁的实锤。所以你在操作系统里学的进程阻塞态在Java线程层面就是BLOCKED状态两者概念是相通的。5.2 状态管理的终极目标让资源利用率、响应时间和公平性达成平衡学到这里你可能会问搞这么多状态管理到底图什么操作系统管理进程追求的目标无非是三个资源利用率CPU、内存、磁盘这些硬件资源尽量别闲着。如果就绪队列里永远有进程等着CPU就一直在干活利用率就高。响应时间用户点击、键盘输入要尽快有回馈。如果调度器让一个后台计算任务霸占CPU 10秒钟你在终端打字就会卡这叫响应时间差。吞吐量单位时间内系统能完成的作业数量。有时候为了吞吐量是可以适当牺牲响应时间的。这三个目标是有矛盾的。比如时间片轮转调度算法把CPU时间切得很碎每个进程轮流用很短的时间响应时间很好但上下文切换开销大CPU利用率受到一定影响。而先来先服务算法实现简单、切换开销小但一个长任务会阻塞后续所有任务响应时间极差。操作系统课程后面会逐一介绍各种调度算法先来先服务FCFS、短作业优先SJF、高响应比优先HRRN、时间片轮转RR、多级反馈队列MFQ等。每学一个算法你都应该回到“进程状态转换”的视角来理解这个算法是从就绪队列里按什么规则挑进程挑出来之后是让它一直运行到阻塞还是运行固定时间片被抢占的进程回到就绪队列的队尾还是队首把这些想明白调度算法就不再是死记硬背而是一套有逻辑的方案集合。5.3 从进程到线程再到协程状态管理的层次演进现代操作系统课程还会涉及一个议题既然进程切换那么贵能不能让它更轻量于是有了线程线程共享进程的地址空间和资源上下文切换成本比进程低得多。再往后有了协程比如Go的goroutine、Python的asyncio连内核态的调度都省了改由用户态自己管理。站在状态管理的角度看这个演进你会发现一件事无论底层还是上层核心思想都是一样的——把“等待”这件事情从阻塞变成挂起、把“切换”变得越来越便宜。在进程层面等待I/O会进入阻塞态由内核调度器管理。在线程层面线程间的同步等待由线程库管理但最终挂起还是牵涉到内核线程调度。在协程层面用户态程序自己保存和恢复执行上下文等待I/O的时候协程主动yield出执行权而不是把自己交给内核所以切换成本极低可以实现十万甚至百万级别的并发。我曾经用Go写过一个高并发服务一开始对goroutine的调度充满好奇它怎么做到一个进程几百万协程的后来去读了一点Go runtime的源码才发现它的调度器本质上就是一个用户态的“就绪队列运行队列”协程在被channel阻塞时会把自己挂到等待队列事件到达后重新放回就绪队列。这套机制和操作系统内核的进程队列思想一模一样只不过实现精细到了用户态。我在实际调优的时候用GODEBUGschedtrace1000跑过一次看到runqueue运行队列长度和waiting等待协程数的变化才算真正把操作系统课程里的队列模型融会贯通了。6. 常见问题与排查技巧实录这部分是我在实际学习和工作里反复踩坑攒下来的经验整理成速查表希望能帮你避开同样的坑。6.1 常见问题速查表问题现象可能原因排查命令 / 处理方式kill -9杀不掉进程进程处于D不可中断睡眠状态等待其I/O完成检查磁盘/网络存储是否有故障系统出现大量Z状态进程父进程没有调用wait()回收子进程定位父进程PID修复代码或重启父进程top显示CPU高但响应慢进程频繁上下文切换或大量进程争抢锁vmstat看cspidstat -w看线程切换必要时调整线程数程序卡死CPU为0%死锁或线程阻塞在等待事件jstackJava、gdbattachC看堆栈系统负载高但CPU利用率低大量D状态进程等待I/Oiostat -x 1查看磁盘I/O确认是否有IO瓶颈一个进程用完所有CPU核心多线程程序没有正确同步线程都在自旋top -H查看线程级CPU占用定位热点线程6.2 排查线上问题的一个经典思路当线上服务卡顿或者CPU异常的时候我按下面这个顺序排查第一步top -H -p pid先看某个进程内部的线程CPU分布。如果只有一个线程CPU跑到100%多半是某个热点功能在死循环或疯狂计算如果线程全都因为等待不到资源而CPU很低那可能是死锁或者锁竞争。第二步vmstat 1看看系统整体的上下文切换数量和阻塞进程数。cs如果上万说明系统在大量切换线程很可能线程池开太大了。第三步用语言的线程转储工具抓当前状态。Java用jstackGo用Ctrl\SIGQUIT打印协程栈C/C用gdb attach。这一步能把卡住的线程现场直接暴露出来。第四步如果你的服务是Docker容器记得在宿主机上看进程状态因为容器内看到的进程就是宿主机的进程。用ps -eo pid,stat,cmd过滤出容器进程可以看到其真实状态。6.3 学习建议怎么把进程状态这块学扎实最后分享一点学习方法上的体会。操作系统这门课纯看书很容易“看懂了但不会用”尤其是进程状态这块光背状态图不如亲手去跑几个实验来得扎实。我的建议是三件事第一写一个带fork()和wait()的小程序亲手创建和管理子进程观察不同阶段的进程状态。这个实验在现代Linux课程或实验室里都很容易复现不需要什么高大上的环境一个gcc终端就够。第二结合具体的多线程框架去验证概念。比如你写Java就去看Thread.State的六种枚举值NEW、RUNNABLE、BLOCKED、WAITING、TIMED_WAITING、TERMINATED和操作系统进程状态的对照。写Go就去看goroutine的runnable、running、waiting状态。你会发现操作系统课程里的“就绪、运行、阻塞”只是不同语言的命名差异。第三把排障命令练成肌肉记忆。ps、top、vmstat、pidstat、kill、jstack这套工具链要滚瓜烂熟。我见过很多人看完操作系统理论能考高分但真到线上服务卡死的时候连ps看状态都不会用这就是理论和实践脱节。操作系统这门课用来应付考试的部分可能一个月就学完了但真正内化成排查问题的直觉需要在实际项目里反复磨。根据我个人经验进程状态是操作系统的“地基”地基稳了后面学内存管理、文件系统、I/O子系统才不至于越学越懵。每次遇到“进程为什么卡”、“资源被谁占了”、“怎么杀掉这个进程”这类问题先回到状态模型上推一遍大概率能找到答案。最后再分享一个小技巧如果你在Linux里想快速看当前系统进程状态的分布可以用这一行命令把所有进程的状态统计出来ps -eo stat | awk {print $1} | sort | uniq -c输出结果会类似3 R 12 S 1 Z这样几个数字一对比你一眼就知道系统到底是在正常轮转、I/O等待还是出现了僵尸泄漏。这就是把状态管理知识用到了点子上。
