为什么IO多路复用需要采用非阻塞式IO

近段时间开始学习《Unix网络编程》，代码实现了一个简单的IO多路复用+阻塞式的服务端，在学习了非阻塞式IO后，有一个疑问，即：

假如调用了select，并且关注了几个描述字，当关注的描述字可读时，select成果返回并告诉我对应套接口已可读，此时采用阻塞式read或非阻塞式read去读套接口有何区别，既然已经告诉套接字可读，调用read怎么还会发生阻塞。即本问题，为什么IO多路复用需要采用非阻塞式IO。

当时理解不深，不知道该问题存在原因，第二天偶然刷知乎，刷到了这个问题。现解释如下：

1、首先看下man select解释：

Under Linux, select() may report a socket file descriptor as "ready for reading", while nevertheless a subsequent read blocks. This could for example happen when data has arrived but upon examination has wrong checksum and is discarded. There may be other circumstances in which a file descriptor is spuriously reported as ready. Thus it may be safer to use O_NONBLOCK on sockets that should not block.

当某个socket接收缓冲区有新数据分节到达，然后select报告这个socket描述符可读，但随后，协议栈检查到这个新分节检验和错误，然后丢弃这个分节，这时候调用read则无数据可读，如果socket没有被设置nonblocking，此read将阻塞当前线程。

 

即select可能存在如下问题：当新数据到达描述符，select返回描述符可读，但Linux内核协议栈检查到新数据包的校验和错误，故丢弃该数据，采用阻塞式IO去读该套接口，无数据可读，则当前进程阻塞。

2、第二种解释有：

一种典型场景，惊群现象：当采用多线程方式通过select或epoll监听套接字，当新连接到达，则所有监听套接字的线程会通过select被唤醒，但是最终只有一个线程会通过accept与这个新连接建立握手关系，如果采用了阻塞式IO，则其余所有没有接收到accept连接的线程会阻塞。