阻塞IO本质是内核主动挂起线程：当数据未就绪时，内核在系统调用返回前将线程置为TASK_INTERRUPTIBLE态并移出就绪队列；每次调用伴随寄存器保存/恢复、TLB刷新、内核栈切换三重开销；线程虽不占CPU，但仍占用task_struct、内核栈、文件描述符等资源；高并发下线程数线性增长，加剧调度负担与内存消耗。

阻塞 IO 的本质是内核主动挂起线程

传统阻塞式 I/O 并非程序“卡死”，而是操作系统在检测到数据未就绪时，将当前线程状态从 运行态（RUNNING） 切换为 阻塞态（TASK_INTERRUPTIBLE），并从 CPU 就绪队列中移除。此时线程不再参与调度，也不消耗 CPU 时间片。关键点在于：这个动作由内核在系统调用（如 recv、read）返回前完成，不是用户代码决定的。

用户态到内核态切换带来三重开销

每次发起阻塞 I/O 请求，都需经历一次完整的上下文切换，涉及以下变量性开销：

• 寄存器保存与恢复：CPU 需将用户态寄存器（如 RSP、RIP、通用寄存器）压栈保存，进入内核态后加载内核栈和寄存器上下文；返回时再反向还原
• 页表切换（TLB 刷新）：用户空间与内核空间使用不同虚拟地址空间，切换时可能触发 TLB miss，导致后续内存访问延迟升高
• 内核栈切换与函数调用链开销：系统调用会进入内核协议栈（如 socket → TCP → IP → 网卡驱动），每层函数调用都增加栈帧与参数传递成本

等待期间线程不占 CPU，但资源仍被持有

虽然阻塞线程不运行，但它持续占用以下不可忽略的资源：

• 内核中对应的 task_struct 结构体 和内核栈（通常 16KB）
• 文件描述符、socket 缓冲区、连接状态等内核对象引用
• 若该线程隶属于某线程池（如 Java 的 ThreadPoolExecutor），其线程实体仍被池管理，无法复用给其他任务

高并发下线程数膨胀放大调度压力

当每个连接绑定一个阻塞线程时，线程数量随连接数线性增长，引发调度器层面的变量开销激增：

• CPU 调度器需维护更长的就绪队列，O(1) 调度器虽优化查找，但遍历所有可运行线程的负载仍上升
• 线程间频繁唤醒/睡眠导致 上下文切换次数飙升（万级连接下可达每秒数万次）
• 线程栈内存占用呈线性增长（如 10K 连接 × 1MB 栈 ≈ 10GB 内存），易触发 swap 或 OOM