进程的阻塞与非阻塞是什么意思？理解高性能开发的基础
你真的掌握阻塞与非阻塞的概念吗？
在软件开发中，**阻塞（Blocking）和非阻塞（Non-blocking）**是描述程序在等待某个操作完成时的核心行为模式。两者的核心区别在于：等待期间，程序是否能继续执行其他任务。
这两个概念广泛应用于并发编程、I/O 处理、网络编程等场景，是理解高并发、高性能系统设计的基础。
``阻塞模型的底层逻辑
首先需要明确一个关键点：阻塞的对象是程序（线程/进程），而不是 CPU。 这一点常被混淆。
当程序执行到某个操作（如 I/O 操作）时，必须等待该操作完全完成后，才能继续执行后续代码。此时，程序会从就绪态转为阻塞态，被调度器移出 CPU 就绪队列，彻底放弃 CPU 使用权，无法处理任何其他任务。
这意味着程序被 I/O 操作“阻塞”住了。直到 I/O 操作完成，操作系统才会将程序拉回就绪队列，等待再次被调度。
简单来说：等完再做。
- 等待期间，线程/进程闲置。
- CPU 可以先处理其他任务。
非阻塞模型的底层逻辑
非阻塞 I/O 的本质是线程与 I/O 解耦。
当程序执行到某个操作时，不会等待该操作完成，而是立即返回一个“操作未完成”的状态（如错误码、空结果等）。之后，程序可以继续占用 CPU 执行其他任务。后续需要通过轮询主动检查或事件通知被动接收完成信号的方式，确认操作是否完成，再处理结果。
简单来说：先做别的，回头再看。
- 等待期间，线程/进程不闲着。
- CPU 持续被利用。
生活实例：咖啡店买咖啡
为了更直观地理解，我们可以用去咖啡店买咖啡的例子来类比：
-
阻塞模式： 你排队点单后，站在取餐口一动不动，全程等待咖啡制作完成。拿到咖啡后才离开，期间不能做其他任何事。这就是阻塞。
-
非阻塞模式： 你点单后拿到一个取餐号，然后去旁边看手机。每隔几分钟看一眼取餐屏（轮询），或者等待店员喊号（事件通知），直到咖啡做好再去取。这就是非阻塞。
阻塞模式的使用场景
在以下三类情况中，优先选择阻塞模式：
-
简单场景，无高并发需求 例如单机日志分析脚本、数据格式转换工具，或者读取本地小型配置文件。这类操作并发量低，耗时短，使用阻塞模式足够且简单。
-
逻辑简单优先的场景 例如后端服务中偶尔进行的小文件读写。使用阻塞模式代码线性执行，无需复杂的状态管理，出了问题调试直观。没必要为了微小的性能提升引入非阻塞的复杂逻辑。
-
CPU 密集型任务 例如大数据排序、复杂算法计算。这类任务本身就需要持续占用 CPU 进行计算，使用阻塞模式不会浪费资源。如果强行使用非阻塞，频繁的轮询反而会增加额外的 CPU 开销，得不偿失。
非阻塞模式的核心适用场景
在以下三类场景中，非阻塞模式是刚需：
-
高并发 I/O 场景 例如 Web 服务器（Nginx, Tomcat）、数据库服务器（MySQL）、消息队列（Kafka）等。这些组件需要同时处理成千上万个客户端请求，每个请求本质都是 I/O 操作。
- 案例：Nginx 之所以能单进程扛住数万个并发连接，核心就是非阻塞 I/O + epoll 架构。如果换成阻塞模式，每个连接配一个线程，数万个线程的上下文切换开销会直接拖垮系统。
-
资源受限场景 例如移动端或嵌入式设备，线程数量有严格限制，不可能为每个 I/O 操作开辟一个线程。此时必须使用非阻塞模式，靠少量线程处理多个 I/O 任务。
-
低延迟需求场景 例如实时通信的 WebSocket 服务、高频交易系统。这些场景对响应延迟要求极高，线程阻塞哪怕几百毫秒都可能造成问题。非阻塞模式能避免等待导致的延迟，保证响应速度。
总结
阻塞与非阻塞的核心区别在于：线程在 I/O 等待期间是否释放 CPU。
- 阻塞模型：简单但低效，适配低并发、逻辑简单或 CPU 密集型场景。
- 非阻塞模型：通过与 I/O 多路复用结合，实现高效并发，但需解决状态管理的复杂度，适用于高并发、资源受限或低延迟场景。
理解这一基础概念，是迈向高性能系统开发的第一步。下一期我们将深入拆解 I/O 多路复用，敬请期待。