打开终端，执行 `python`，当屏幕出现交互提示符而我们还没有输入内容时，Python 解释器并没有退出。它仍然作为一个进程存在，却没有必要持续占用 CPU 执行计算。对于常见的终端交互方式，它会在等待输入时进入等待状态，直到输入条件满足，才有机会继续执行。

这个日常操作，正好揭示了题目中最关键的遗漏。

本题应选 **C**。进程的三种基本状态是就绪状态、运行状态和阻塞状态，也称等待状态。选项 C 只写了就绪和运行，漏掉了阻塞，因此描述错误。操作系统课程中也经常采用五状态模型，在这三种状态之外加入新建和终止，用来描述更完整的进程生命周期。[cs.uic.edu](https://www.cs.uic.edu/~jbell/CourseNotes/OperatingSystems/3_Processes.html?utm_source=chatgpt.com)

这道题的难点，并不是背出三个状态名称，而是理解两个容易混淆的说法。一个是日常语言中的「程序正在运行」，另一个是操作系统状态模型中的「进程处于运行态」。前者通常表示软件已经启动、尚未结束，后者有更严格的含义，指处理器此刻正在执行它的指令。

只要把这两层含义分开，四个选项就能串成一条清楚的逻辑。

程序规定怎样完成任务，进程承载某一次实际执行，而执行中的进程需要在计算、等待处理器、等待外部事件之间切换。这三种情况对应运行、就绪和阻塞，缺少任何一种，都无法准确说明普通程序的执行过程。

说到程序，我们很容易想到磁盘上的可执行文件，例如 Linux 系统中的 `/usr/bin/python3`。在没有启动它的时候，这个文件仍然存在，里面保存着可供执行的代码以及相关数据。即使关机，只要存储设备中的文件没有被删除，程序也不会因为某个进程结束而消失。

选项 D 所说的「程序是指令和数据的有序集合」，正是在这个层面上概括程序。

指令描述需要完成的操作，数据为操作提供对象、常量或者初始内容。有序也不等于必须从文件开头一路执行到结尾。条件分支、循环和函数调用都会改变执行路径，但这些变化仍受程序结构和指令语义约束，并不是任意发生的。

一个计算商品总价的程序，可以包含读取单价、读取数量、计算乘积和输出结果的指令，也可以包含税率、提示文字、初始配置等数据。只看这些静态内容，我们知道计算应当怎样进行，却不知道某一次执行已经算到哪一步，也不知道当前处理的是哪张订单。

这些属于实际执行的信息，要进入进程的范围讨论。

同一份程序被启动后，操作系统需要为这次执行建立相应的管理信息。当前执行位置、内存中的变量、打开的文件、使用的通信连接，以及处理器寄存器中需要保留的内容，都与这次执行有关。

因此，把程序文件直接等同于进程，就会丢失执行现场。

可以把菜谱与实际做菜作一个有限的类比。菜谱写着食材、用量和操作方法，它不会因为厨房暂时没有开火而消失。真正开始做某一份菜时，才会出现这次操作特有的进度，例如食材是否切好、锅是否预热、当前放了多少盐。

程序与进程的关系也有相似之处。程序描述做法，进程体现某一次做法的实际展开。这个类比只用于区分静态描述与动态执行，实际的进程还涉及地址空间、系统调用和资源管理，不能完全照搬厨房中的细节。

回到选项 A，「进程是正在运行的程序的实例」属于常见的入门定义，应当判为正确。

这里的实例，可以理解为按照同一份程序建立起来的一次具体执行。同一份代码可以产生不同的执行实例，各实例拥有各自的运行进度和数据状态。

选项 A 中的「正在运行」，应按广义的执行过程理解。它没有要求这个进程在每一个时刻都占据 CPU。一个进程在等待键盘输入、等待磁盘数据或者等待另一个任务完成时，仍然是已经启动的程序实例。

假如把选项 A 中的「正在运行」机械地解释成「此刻处于运行态」，就会得到一个很奇怪的结论，进程一旦被调度出去，就突然不再是进程，等重新获得 CPU 时又变成进程。操作系统显然不会这样管理执行活动。

进程身份不会随着一次普通的调度切换反复消失。变化的是它当前所处的状态。

这也是为什么任务管理工具中能看到大量 CPU 使用率接近零的进程。它们可能正在等待输入或者其他事件，也可能只在很短的时间里执行少量工作。CPU 使用率反映一段统计时间内的处理器使用情况，不能直接用来判断一个进程是否存在。

再看选项 B，「同一个程序可以对应多个进程」，也是正确的。

这种关系在服务器软件中非常常见。NGINX 官方文档介绍了它的主进程和工作进程结构，主进程负责读取、检查配置以及管理工作进程，工作进程负责处理请求。一个软件的运行，可以由多个进程共同承担。[nginx.org](https://nginx.org/en/docs/beginners_guide.html?utm_source=chatgpt.com)

这并不是把一个进程在任务列表里显示多次，而是操作系统管理着多个不同的执行实体。它们可以执行相同或相关的代码，却具有不同的身份和执行现场。

更直接的例子是 Python。我们在两个独立终端中分别启动同一个 Python 解释器，通常会得到两个不同的解释器进程。一个终端中定义的普通变量，不会因为解释器程序相同，就自动出现在另一个终端中。

两个进程可以运行相同的程序代码，同时处理不同输入。一个正在做整数计算，另一个正在等待终端输入，它们的进度也完全可以不同。

因此，判断是不是同一个进程，不能只看程序名称，还需要关注进程标识以及相关的运行上下文。程序名称相同，不代表进程身份相同。

Linux 的 `fork()` 机制提供了更具体的技术例证。它可以创建子进程，子进程具有自己的进程标识，并与父进程拥有分离的内存空间。创建时两者的内存内容可以相同，但对于普通私有内存，一方后续的修改不会自动成为另一方的修改。[Linux manual page](https://man7.org/linux/man-pages/man2/fork.2.html?utm_source=chatgpt.com)

这也说明，多进程与程序文件数量并不存在简单的一一对应关系。

同一份程序可以没有任何进程，因为它尚未启动；也可以对应一个进程；还可以对应多个进程。某个进程结束，也不等于程序文件被删除，更不等于其他执行同一程序的进程必须一起结束。

不过，多进程也不要求每个进程都完整复制一份物理内存中的程序代码。操作系统可以共享适合共享的只读代码页，同时为不同进程维护各自的私有数据和执行状态。进程独立与物理存储完全不共享，是两个不同的问题。

这样再看选项 C，错误就很明确了。

就绪态表示，进程已经具备继续执行所需要的条件，目前主要缺少的是 CPU。只要调度器选中它，就能够继续执行。

运行态表示，处理器正在执行这个进程中的指令。在基础教学采用的单执行流模型中，可以把它理解为进程已经得到处理器，正在向前推进。

阻塞态表示，进程正在等待某个事件或条件满足，在这个条件满足之前，单纯给它 CPU 也不能让所等待的操作正常完成。

就绪和阻塞都可能表现为「当前没有执行」，但它们没有执行的原因不同。就绪是在排队等处理器，阻塞是在等继续推进所必需的条件。

我们可以把视线放回终端里的 Python 解释器。

当它正在处理已经输入的算式时，需要执行解析、计算和输出等指令，这属于运行阶段。如果处理器暂时去执行另一个可运行任务，而 Python 解释器仍然有工作可以继续做，它就处于就绪状态。

当解释器已经准备读取下一行输入，但终端暂时没有新输入时，在通常的阻塞式读取路径中，它会等待输入事件。此时阻塞的原因不是处理器不够快，而是需要的数据尚未到达。

即使把处理器换成速度更快的型号，也不能让尚未发生的键盘输入提前出现。

这就是阻塞态必须独立存在的原因。操作系统需要区分「有工作可做，只差处理器」和「当前条件不满足，暂时没有办法继续」。不作区分，就可能把大量处理器时间浪费在反复检查尚未完成的事情上。

不过，不能看到源代码中出现读取操作，就断言一定发生阻塞。读取的数据可能已经在缓冲区中，调用也可能采用非阻塞方式。是否进入阻塞态，要看具体调用语义以及调用发生时的条件。

软考题目通常会明确使用「等待输入」「等待磁盘操作完成」「等待资源」等表述。遇到这些条件，我们要抓住的不是程序调用了什么名字的函数，而是它是否因为条件尚未满足而暂停推进。

为了把三种状态之间的关系想清楚，可以沿着一段执行过程观察。

一个已经就绪的进程获得 CPU，进入运行态。它执行了一段时间，时间片用完，或者调度器决定让另一个任务执行，就可能回到就绪态。这个时候，它不是发生了故障，也不一定需要等待外部事件，只是处理器使用权发生变化。

如果它在运行中发起一个必须等待完成的操作，例如读取当前尚未就绪的数据，就会进入阻塞态。等待期间，操作系统可以安排其他就绪任务使用 CPU。

等到数据到达，阻塞条件解除，它通常先恢复为就绪状态，等待调度器安排执行。

「阻塞解除」和「立即运行」之间，不能直接画等号。

数据已经准备好，只能说明进程重新具备运行条件。处理器可能仍在执行其他任务，也可能存在更高优先级的就绪任务。它最终何时获得处理器，还要由调度策略以及当时的系统状态决定。

在基础三状态模型中，我们据此记住四种核心转换，分别是就绪转运行、运行转就绪、运行转阻塞、阻塞转就绪。这里不用把每条转换孤立背诵，只要问清楚变化来自处理器分配，还是来自等待条件的改变，就很容易判断。

就绪转运行，是获得处理器。

运行转就绪，是暂时失去处理器，但仍然能够继续执行。

运行转阻塞，是执行过程中遇到尚未满足的条件。

阻塞转就绪，是等待条件已经满足，重新取得参与调度的资格。

按照这个模型，进程不会仅仅因为没有拿到 CPU，就从就绪态进入阻塞态。没有拿到 CPU，正是就绪队列存在的常见原因。把这种排队也叫作阻塞，就会把两个状态重新混在一起。

同样，阻塞进程被唤醒，也不能理解为它可以跳过所有调度规则，直接抢到处理器。即使在某次实际执行中，唤醒之后很快就发生调度，我们仍然需要区分「已经可以运行」与「已经开始运行」。

这两个动作在时间上可能挨得很近，在概念上却分别回答不同问题。

说到这里，题干中的「运行中的进程」也值得再读一遍。日常表达可能把它理解成「已经启动且尚未结束的进程」，这类进程当然可能处于就绪、运行或者阻塞状态。若严格理解为「已经处于运行态的进程」，再说它同时拥有就绪和运行两种状态，也不合适。

不过，本题的考查重点很清楚，就是基本状态中遗漏了阻塞。考试时不需要绕进措辞争论，识别出这个遗漏，就能稳定选出 C。

实际系统里的状态名称有时会让复习产生新的疑问。例如，在 Linux 中使用 `ps` 查看进程时，状态代码 `R` 可以表示正在运行，也可以表示可运行；`S` 表示可中断睡眠，`D` 表示不可中断睡眠，通常与输入输出等待有关。工具呈现的分类，并不要求与教材三状态模型逐项同名。[Linux manual page](https://man7.org/linux/man-pages/man1/ps.1.html?utm_source=chatgpt.com)

这不代表教材多分了一个状态，也不代表 Linux 不需要区分等待与可运行。理论模型主要帮助我们理解调度关系，实际内核和诊断工具则有各自的表示方式，可能合并某些状态，也可能细分某些等待情况。

因此，不能拿某个工具显示的状态字母数量，直接推翻软考中的基本状态结论。

同样，五状态模型也不会使本题变成另一种答案。三状态模型关注进程执行期间最核心的三种情况，五状态模型补充创建和结束阶段，描述范围更完整。两种模型都承认进程可能因为等待事件而暂时无法继续执行。

扩展到包含挂起状态的模型时，还会涉及进程是否被暂时移出内存等管理因素。这些内容可以帮助理解操作系统，但对当前题目来说，决定答案的仍然是阻塞态的缺失。

我们还可以从性能分析的角度检验这个结论。

一个程序响应很慢，并不自动说明它需要更强的 CPU。如果主要时间花在就绪队列里，可能与处理器竞争、优先级或调度有关。如果主要时间花在等待磁盘、网络或者锁上，瓶颈就可能在这些等待条件。

如果它一直得到 CPU，并持续执行大量计算，才更接近计算密集的情况。

同样是用户界面暂时没有变化，背后的状态可能完全不同。区分就绪、运行和阻塞，能够把「软件很慢」拆成更具体的问题，究竟是没有获得执行机会，正在努力计算，还是等待某件事情完成。

但在现代多线程程序中，分析还需要进一步落到线程。一个进程里的某个线程可能正在等待网络，另一个线程仍在计算。不能看到一个线程阻塞，就断言整个进程内所有执行活动都停止。

基础题目通常采用简化的单执行流模型来讲进程状态，这样更容易突出调度原理。理解这个前提，就能在做题时使用正确模型，也能在实际排障时避免把简化模型套得过死。

还有一种情况能够帮助划清边界，就是忙等待。

程序可以通过循环不断检查某个条件是否满足。这时它虽然在日常语义上「等待结果」，却可能一直执行检查指令，持续消耗 CPU。它并没有因为等待这个结果，就自动进入操作系统的阻塞态。

真正进入阻塞态，通常需要相应机制使执行暂停，并在条件满足时被唤醒。等待是一种业务上的描述，阻塞态则是操作系统状态，二者不能只凭文字相似就混为一谈。

这也让我们更准确地理解进程与程序的区别。程序里写着哪些操作，只描述了可能发生的行为；某个进程此刻是否正在执行、是否被调度出去、是否等待输入，还取决于实际输入、资源状况和系统调度。

同一份程序建立的两个进程，可能在同一时刻处于不同状态。一个已经读到数据，正在计算；另一个尚未读到数据，正在阻塞。程序相同，不会使它们的状态被强制同步。

回到这道题，A 描述程序的一次执行实例，B 描述同一程序可以具有多个执行实例，D 描述程序由指令和数据构成，这三个说法都符合基础概念。C 把进程基本状态缩减为就绪和运行，无法容纳等待输入、等待输入输出完成等常见情况，因此应当选 C。

记忆时可以抓住一句话，运行是在用 CPU，就绪是在等 CPU，阻塞是在等继续执行所需的事件或条件。程序已经启动，并不要求它每一刻都在执行指令；进程暂时没有执行，也不代表它已经结束。

参考资料

[伊利诺伊大学芝加哥分校，操作系统课程中的进程概念与状态模型](https://www.cs.uic.edu/~jbell/CourseNotes/OperatingSystems/3_Processes.html)

[Linux man-pages，fork 系统调用](https://man7.org/linux/man-pages/man2/fork.2.html)

[NGINX 官方文档，主进程与工作进程](https://nginx.org/en/docs/beginners_guide.html)

[Linux man-pages，ps 命令及进程状态代码](https://man7.org/linux/man-pages/man1/ps.1.html)

打开终端，执行 python，当屏幕出现交互提示符而我们还没有输入内容时，Python 解释器并没有退出。它仍然作为一个进程存在，却没有必要持续占用 CPU 执行计算。对于常见的终端交互方式，它会在等待输入时进入等待状态，直到输入条件满足，才有机会继续执行。

进程还活着，为什么却不运行？从一道软考题理解程序、进程与三种基本状态

紫薇堂堂主

人工智能

题目考查进程三态模型，C选项遗漏“阻塞态”故错误。就绪态等待CPU，运行态占用CPU，阻塞态等待事件。程序是静态指令集合，进程是动态执行实例，同一程序可对应多进程。区分日常“运行中”与严格“运行态”是关键。

服务器

解释器

Python

Linux

Nginx

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

进程还活着，为什么却不运行？从一道软考题理解程序、进程与三种基本状态-腾讯云开发者社区-腾讯云

进程还活着，为什么却不运行？从一道软考题理解程序、进程与三种基本状态

进程还活着，为什么却不运行？从一道软考题理解程序、进程与三种基本状态

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐