NIO、BIO和IO多路复用总结

转载自https://www.jianshu.com/p/ef418ccf2f7d

BIO

读取时如果数据还没准备好，则阻塞线程。

缺点

发生上下文切换，一个线程管理一个io

NIO

不阻塞，读取时如果还没数据准备好，则返回-1。

缺点

如果都多个io，需要一个一个检测，每次检测调用read都会发生上下文切换（read是系统调用，每调用一次就得在用户态和核心态切换一次）

第一次读取不到时，不知道应该等待多久再尝试读取一次

IO多路复用

IO多路复用（IO Multiplexing) 是这么一种机制：程序注册一组socket文件描述符给操作系统，表示“我要监视这些fd是否有IO事件发生，有了就告诉程序处理”。
IO多路复用和NIO是要配合一起使用才有实际意义。
IO多路复用有select、poll、epoll三种方式。

select

select只有一个函数，调用select时，需要将监听句柄和最大等待时间作为参数传递进去，select会发生阻塞，直到一个事件发生了，或者等到最大1秒钟(tv定义了这个时间长度）就返回。

缺点

select返回后要挨个遍历fd，找到被“SET”的那些进行处理

select是无状态的，即每次调用select，内核都要重新检查所有被注册的fd的状态。select返回后，这些状态就被返回了，内核不会记住它们；到了下一次调用，内核依然要重新检查一遍。于是查询的效率很低

select能够支持的最大的fd数组的长度是1024

poll

poll优化了select的一些问题，参数变得简单一些，没有了1024的限制。但其他的问题依旧。

缺点

依然是无状态的，性能的问题与select差不多一样

应用程序仍然无法很方便的拿到那些“有事件发生的fd“，还是需要遍历所有注册的fd

epoll

使用epoll时，需要先使用函数epoll_create()在内核层创建了一个数据表，接口参数是一个表达要监听事件列表的长度的数值（会动态改变的）。这样一来，不用每次监听都要传一遍fd（传递fd会导致fd数据从用户态复制到内核态）。
创建完数据表，就可以使用另外一个函数epoll_ctl()来管理数据表，对监听的fd执行增删改操作。
最后再调用epoll_wait()方法等待事件的发生。

优点

为什么epoll的性能比select和poll要强呢？ select和poll每次都需要把完成的fd列表传入到内核，迫使内核每次必须从头扫描到尾。而epoll完全是反过来的。epoll在内核的数据被建立好了之后，每次某个被监听的fd一旦有事件发生，内核就直接标记之。epoll_wait调用时，会尝试直接读取到当时已经标记好的fd列表，如果没有就会进入等待状态。

同时，epoll_wait直接只返回了被触发的fd列表，这样上层应用写起来也轻松愉快，再也不用从大量注册的fd中筛选出有事件的fd了。

epoll除了性能优势，还有一个优点——同时支持水平触发(Level Trigger)和边沿触发(Edge Trigger)。

水平触发和边沿触发

考虑下图中的例子。有两个socket的fd——fd1和fd2。我们设定监听f1的“水平触发读事件“，监听fd2的”边沿触发读事件“。我们使用在时刻t1，使用epoll_wait监听他们的事件。在时刻t2时，两个fd都到了100bytes数据，于是在时刻t3, epoll_wait返回了两个fd进行处理。在t4，我们故意不读取所有的数据出来，只各自读50bytes。然后在t5重新注册两个事件并监听。在t6时，只有fd1会返回，因为fd1里的数据没有读完，仍然处于“被触发”状态；而fd2不会被返回，因为没有新数据到达。

这个例子很明确的显示了水平触发和边沿触发的区别。

水平触发只关心文件描述符中是否还有没完成处理的数据，如果有，不管怎样epoll_wait，总是会被返回。简单说——水平触发代表了一种“状态”。
边沿触发只关心文件描述符是否有新的事件产生，如果有，则返回；如果返回过一次，不管程序是否处理了，只要没有新的事件产生，epoll_wait不会再认为这个fd被“触发”了。简单说——边沿触发代表了一个“事件”。

Netty的 epoll transport使用 epoll edge-triggered 而 java的 nio 使用 level-triggered。