IO多路复用技术（multiplexing）

Posted 2020-10-14 欧耶d

一、举例说明

　　假设你是一个老师，让30个学生解答一道题目，然后检查学生做的是否正确，你有下面几个选择：

1. 第一种选择：按顺序逐个检查，先检查A，然后是B，之后是C、D。。。这中间如果有一个学生卡主，全班都会被耽误。
这种模式就好比，你用循环挨个处理socket，根本不具有并发能力。
2. 第二种选择：你创建30个分身，每个分身检查一个学生的答案是否正确。 这种类似于为每一个用户创建一个进程或者线程处理连接。
3. 第三种选择，你站在讲台上等，谁解答完谁举手。这时C、D举手，表示他们解答问题完毕，你下去依次检查C、D的答案，然后继续回到讲台上等。此时E、A又举手，然后去处理E和A。。。
这种就是IO复用模型，Linux下的select、poll和epoll就是干这个的。将用户socket对应的fd注册进epoll，然后epoll帮你监听哪些socket上有消息到达，这样就避免了大量的无用操作。此时的socket应该采用非阻塞模式。
这样，整个过程只在调用select、poll、epoll这些调用的时候才会阻塞，收发客户消息是不会阻塞的，整个进程或者线程就被充分利用起来，这就是事件驱动，所谓的reactor模式。

（作者：郭春阳
链接：https://www.zhihu.com/question/28594409/answer/52835876
来源：知乎）
二、技术说明

技术上的问题，是将IO操作中等待和非等待的部分分开处理。我们都知道IO操作分为两个部分：
1、等待数据就绪
2、处理数据

 

众所周知的几种IO模型（阻塞、非阻塞、多路复用、信号驱动、异步）就是区别于这两个阶段，当需要处理很多连接的时候（高并发的情况），容易想到的是使用多线程技术，比如最简单的One-connection-Per-thread模式，但是因为等待数据不可避免，造成的结果是线程不停的休眠-唤醒的切换，导致CPU不堪重负。

IO复用的目的：将这两个阶段分开处理，让一个线程（而且是内核级别的线程）来处理所有的等待，一旦有相应的IO事件发生就通知继续完成IO操作，虽然仍然有阻塞和等待，但是等待总是发生在一个线程，这时使用多线程可以保证其他线程一旦唤醒就是处理数据，当然这需要非阻塞IO API的支持（比如非阻塞套接字）。Linux2.6之前的select,poll以及之后的epoll都是IO复用技术的实现。select和poll基本一致，epoll是对它们的改进版本。但总的来说它们都还不是真正的异步IO，因为它们在IO读写的时候仍然是阻塞的、同步的（完成一件事后才能做另外一件事）。异步IO是指“处理数据”这一阶段也是非阻塞的。Windows上的IOCP（完成端口）才是真正的AIO，理论上它比Linux的epoll更先进。

至于select、poll和epoll的区别，推荐这篇文章：http://www.cnblogs.com/Anker/p/3265058.html。简单来说：select,poll无脑的轮询，忽略了高并发下，轮询本身成了瓶颈，而epoll使用回调实现了轮询真正需要处理的连接。

 

Reactor模式是为了我们更简单的使用IO复用技术。它是一种并发IO模式，其他的模式还有多进程，多线程等。Reactor本身也有很多变种，比如thread per request,worker thread,thread pool，multiple reactors...网上这方面的资料很多。虽然网上关于reactor和多线程模孰优孰劣还有争论(Reactor最明显的一个缺点是无法充分利用多核的优势)，但是大部分高并发的框架或组建都是基于reactor的，比如MINA,Netty，再比如Redis,nginx(有多个工作进程来充分利用多核的优势)。关于Java中的IO复用可以看Doug Lea大神的Scalable IO in Java（http://gee.cs.oswego.edu/dl/cpjslides/nio.pdf）。