进程中断后进入就绪队列还是阻塞队列的判定规则咨询

你之前的记忆存在认知偏差：不存在“中断发生后进程一定进就绪队列”的固定规则，进程中断后进入哪个队列，核心判断依据是中断处理完成后，当前进程是否具备立即继续运行的条件，和中断本身的类型、触发原因直接相关，两类场景的边界非常清晰：

这类场景的共性是：当前进程本身没有需要等待的事件，只是因为中断触发了调度逻辑，需要暂时让出CPU，随时可以恢复运行。

• 时钟中断触发的时间片耗尽：抢占式调度系统中，进程分配的时间片用完后，时钟中断会触发调度程序，此时进程没有任何待等待的资源或事件，会被移入就绪队列，等待后续调度再次分配CPU。
• 无关进程唤醒触发的I/O中断：比如某个等待磁盘/网络I/O的高优先级进程拿到了数据，I/O中断触发调度程序发现当前运行的进程优先级更低，需要让权给刚就绪的高优先级进程，此时当前运行的进程本身没有阻塞诉求，会被移入就绪队列。
• 其他不涉及当前进程资源等待的中断：比如进程收到信号触发的信号处理中断、调试断点触发的调试中断等，中断处理完成后进程本身可以直接继续运行，仅因为中断流程触发了调度才暂时进入就绪队列，通常很快就会被重新调度执行。

你图中标注的中断后进程进入阻塞队列，对应的就是这类场景，核心共性是：中断本身就是当前进程触发的，且中断处理流程中发现进程必须等待某个特定事件发生才能继续运行，不具备立即执行的条件，和“中断”这个触发动作没有关系，本质是进程的等待诉求借由中断处理流程完成了状态切换，常见场景包括：

• 进程发起系统调用触发软中断：进程运行过程中主动调用read()、wait()这类需要等待资源/事件的系统调用时，会通过陷入指令触发软中断进入内核态，内核判断进程申请的资源（比如磁盘数据、用户输入、锁/信号量）暂时无法获取，就会在中断处理流程中把进程标记为阻塞状态，移入对应资源的等待队列，直接调度其他就绪进程运行，直到等待的事件发生后才会被唤醒回就绪队列。
• 进程运行触发同步异常（本质是同步中断）：最典型的就是缺页中断——进程访问的虚拟内存页还没加载到物理内存时，会触发缺页异常，内核需要从磁盘加载对应页，这个过程耗时较长，进程无法继续向下执行，就会被暂时移入阻塞队列，等页加载完成后再唤醒。

很多基础教材讲进程状态流转时，举的中断例子大多是时钟中断这类和当前进程等待事件无关的外部中断，没有覆盖软中断、同步异常触发阻塞的场景，才会让你觉得和图中的流程矛盾。本质上进程进入阻塞队列的唯一判定标准是“进程必须等待某事件发生才能继续运行”，只要满足这个条件，不管是在什么中断的处理流程中，都会被移入阻塞队列，不存在和中断类型的强制绑定。

内容的提问来源于stack exchange，提问作者Blue And Red