Linux I/O 多路复用的实际工作方式：文件描述符、阻塞与事件循环

I/O 多路复用常被简单理解成“一个线程处理很多连接”，但它首先解决的是等待问题。线程把多个文件描述符交给内核后，不需要轮流对每个连接做阻塞读取，而是等待一批对象中至少有一个满足条件。

当内核返回就绪结果时，线程再根据结果选择需要处理的连接。连接数量很多并不代表每个连接都同时活跃，事件循环把计算时间集中在真正有数据或有空间的对象上，避免大量线程在没有事件时各自睡眠和唤醒。

阻塞读取的含义是：如果当前没有数据，读取调用不会立即返回，而是让线程等待，直到有数据、连接关闭或发生错误。对单个连接来说，这种方式简单自然；但当同一个线程还负责其他连接时，一个连接的沉默就可能拖住全部连接。

阻塞写入也可能等待发送缓冲区出现空间。数据量大、对端读取慢或网络拥塞时，写操作可能停留较长时间。事件循环通常会关注可写条件，只在内核提示暂时可以发送时推进一部分数据，而不是一次提交所有内容。

将描述符设置为非阻塞后，读取和写入不会因为暂时没有条件而长时间停住。没有数据时，读取会返回相应状态；发送缓冲区没有空间时，写入也会告诉程序稍后再试。线程因此可以回到事件循环，继续处理其他连接。

非阻塞并不意味着操作一定成功，也不意味着程序可以忽略返回值。应用必须区分“暂时没有数据”“连接已经关闭”和“真正发生错误”，并保存尚未发送完的数据。状态管理的复杂度从内核等待转移到了应用逻辑中。

一个典型事件循环会先准备监听套接字和已有连接，再把需要关注的读写事件交给内核。等待调用返回后，程序遍历就绪事件：新连接到来时接受连接，有数据时读取，有待发送数据时继续写出，连接关闭或出错时清理对应状态。

处理结束后，程序根据连接当前状态更新下一轮关注的事件。例如发送缓冲区为空时不必持续关注可写；缓冲区重新有数据时再关注写事件。这样可以减少无意义的可写通知，保持事件循环的工作量可控。

服务器套接字主要负责等待新的连接请求，已建立的客户端套接字则负责收发具体数据。它们都使用文件描述符，却对应不同的事件含义。监听描述符可读，通常表示队列里有连接可以接受；客户端描述符可读，通常表示有数据、连接关闭或错误等待处理。

把监听描述符和客户端描述符混在一起理解，容易在事件处理时做错操作。事件循环需要根据描述符保存的连接类型决定调用接受、读取、写入还是关闭逻辑。一个整数句柄背后仍然对应着一份完整的连接状态。

网络发送并不保证一次把应用准备好的全部数据都交给内核。发送缓冲区剩余空间有限时，写入可能只接受前面一部分字节。剩余内容必须保存在应用自己的发送缓冲区中，并在下一次可写事件到来时继续发送。

因此，事件循环不能把“可写”理解成“所有数据都能写完”。每次写入后都要移动缓冲区的读取位置，写完后取消可写关注，仍有剩余时继续关注。这个细节直接关系到大响应、慢客户端和高并发连接下的数据完整性。

水平触发关注的是当前状态：缓冲区还有数据，就继续报告可读；发送空间仍然存在，就可能继续报告可写。程序一次没有处理完，下一轮仍有机会继续推进，逻辑比较宽松。

边缘触发关注状态变化。程序收到通知后通常要循环读取或写入，直到返回暂时不可用，否则剩余数据可能没有新的变化事件来提醒。它可以减少重复通知，但要求连接状态、缓冲区和非阻塞返回值配合得更严密。

事件循环的线程如果在某个连接上做很重的计算，其他连接即使已经就绪也要等待。多路复用减少了等待线程数量，却不会自动解决业务处理耗时的问题。解析大文件、复杂计算或慢速外部调用都可能堵住事件循环。

常见做法是把工作拆成较小的步骤，尽快回到事件循环；需要长时间计算时交给其他工作线程或进程；等待外部结果时使用适合的异步接口。关键不是把所有工作都塞进一个线程，而是避免一个连接独占处理机会。

三者都可以作为事件循环的等待入口。select 用集合和位图表示关注对象，poll 使用动态数组，epoll 把关注关系保存在内核事件表中并返回就绪对象。它们改变的是等待和筛选的实现方式，不会替应用完成协议解析、缓冲管理和业务调度。

选择机制时，可以先看连接规模和平台要求，再看触发模式、连接状态数量以及团队对复杂度的承受能力。Linux 大量连接场景常用 epoll，但接口选择只是基础，正确处理关闭、错误、半包、部分写入和超时才是事件循环能否稳定运行的关键。

文件描述符代表内核对象，非阻塞模式让单次操作快速返回，多路复用负责等待多个描述符，事件循环负责根据就绪结果推进连接状态。读事件推动接收缓冲，写事件推动发送缓冲，关闭和错误事件推动资源回收。

把这几个概念放在同一条链上，就能解释许多现象：为什么没有数据时线程不会忙等，为什么一个连接的慢写会拖住自己而不是所有连接，为什么一次可读事件可能需要多次读取，以及为什么 epoll 本身不能替代业务层的状态管理。