转载自//www.greatytc.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。
