epoll、poll、select的比较

在Linux套接字编程的时候，为了处理大量客户的链接请求，需要使用非阻塞的I/O复用，select、poll、epoll是Linux API提供的IO复用方式，epoll是从Linux2.6以后的版本才加入的，在高性能服务器领域有了广泛的应用。

select

本质上是通过设置或存放fd标志位的数据结构来进行下一步处理，有如下的缺点：

■单个进程可监视的fd数量被限制
■需要维护一个用来存放大量fd的数据结构，这样会使得用户空间和内核空间在传递该结构时复制开销大
■对fd表进行扫描占用CPU
■多线程要求复杂的同步控制机制

poll
本质上和select没有区别，它将用户传入的数据copy到内核空间，然后查询每个fd对应的设备状态，如果设备就绪，则在设备等待对了中加入一项并继续遍历，如果遍历完所有的fd后没有发现就绪设备，则挂起当前进程，直到有设备就绪或超时，被唤醒后又要再次遍历fd表。这个过程经历了多次没有意义的遍历。

■由于fd表使用链表存储，它所能监视的fd数量没有限制
■和select同样，大量的fd被整体复制于内核态和用户态，而不管这样的复制是不是有意义
■poll的一个特点，如果报告了fd后没有被处理，则下次poll时会再次报告该fd

epoll
epoll是在linux2.6以后添加进内核的，它支持水平触发和边沿触发，它只告诉进程哪些fd刚刚变为就绪态，并且只会通知一次，与上面两种方式不同，epoll使用mmap减少复制的开销。

epoll使用“事件”的驱动方式，通过向epoll注册fd，一旦该fd就绪，内核就会采用类似回调函数的机制来激活该fd，epoll_wait便可以收到通知。

这种方式最大的连接数虽然有限制，但是很大：1G的内存可以打开10万左右的连接，2G内存可以打开20万左右的连接 。

性能效率比较
select和poll都会因为每次调用都会对线性表进行全部的扫描，所以随着fd的增加会造成遍历速度变慢。

epoll是内核保存有每个fd的callback函数来实现的，只有活跃的socket才会主动调用callback，所以在活跃socket较少的情况下，不会有上面两种方式的性能下降问题。但是如果所有的socket都很活跃，可能会有性能问题。

综上：在选择select、poll、epoll时要根据具体的使用场合以及三种方式的自身特点，标明看epoll的性能最好，但是在连接数少并且都十分活跃的情况下，select和poll的性能可能比epoll好，毕竟epoll的通知机制需要很多函数回调。

Java中阻塞IO和NIO的比较
■阻塞IO
当客户端连接了服务端，服务端必须给该连接新建进程或线程来处理该客户的请求，否则会阻塞在其他的线程上，影响系统的正常运行。这样就产生了如下的问题：

1）客户端过多的时候，会创建大量的处理线程或进程，并且每个线程都需要占用栈空间和一些CPU时间。

2）阻塞可能带来频繁的上下文切换，并且大部分切换是无意义的。

■NIO（noblocking I/O）
非阻塞的IO工作原理如下：

1）由一个专门的线程来出来所有的IO事件，并负责分发。

2）事件驱动：当事件发生的时候会触发调度对应的IO，而不是去循环监视事件的发生。

3）线程通信：线程之间是通过wait和notify等方式通信，保证每次上下文是有意义的。

 

 

运行在Linux平台下，Java的NIO会调用操作系统的select或epoll来实现。