Java IO详解
名词解释
epoll
epoll是Linux内核的可扩展I/O事件通知机制[1]。它设计目的只在取代既有POSIX select(2)与poll(2)系统函数，让需要大量操作文件描述符的程序得以发挥更优异的性能(举例来说：旧有的系统函数所花费的时间复杂度为O(n)，epoll则耗时O(1)[2])。epoll与FreeBSD的kqueue类似，底层都是由可配置的操作系统内核对象建构而成，并以文件描述符(file descriptor)的形式呈现于用户空间。
IOCP
从Input/Output Completion Port获得的缩写, 是一个应用程序调用功能，在Windows NT的3.5版本以后，[1]或是AIX 5版以后，[2]或Solaris第十版以后，开始支援。用于同时地执行多个异步输入然后输出操作。 这样的输入然后输出完成端口，关联着具有一定数目的Socket和文件控制端。 当从目标对象物件中提出了输入输出服务请求，执行完成状态由一条排队在IO端口的中消息指明。 请求提出输入输出服务的进程不收到这个服务的执行完成状态的通知； 要检查输入然后输出完成状态的端口对应的消息队列，获取之前发出输入然后输出请求操作的状态（差不多了观察/操作/模型的分离的重新实现）。 即：”I”/”O”“completion”的”port”管理着多个执行续线程同它们的并发执行原则。 请参考三个系统的API说明。
libevent
libevent是一个异步事件处理软件函式库，以BSD许可证发布。
libevent提供了一组应用程序编程接口（API），让程序员可以设定某些事件发生时所执行的函式，也就是说，libevent可以用来取代网络服务器所使用的事件循环检查框架。
由于可以省去对网络的处理，且拥有不错的效能，有些软件使用libevent作为网络底层的函式库，如：memcached、Tor。
目前libevent支持以下的方式判断IO事件：
poll(2)
select(2)
几乎所有的Unix平台都有提供的函式。
/dev/pool
以Solaris平台为主。
kqueue(2)
以BSD平台为主。
epoll(2)
以Linux平台为主。
nginx
Windows版本的nginx使用原生Win32 API实现（而不是使用Cygwin模拟）。现在只使用了select()连接处理方法，所以高性能和可扩展性就不要想啦，加上还有很多其他的问题，现在Windows 版本的nginx也就是一个BETA版本。Version of nginx for Windows uses the native Win32 API (not the Cygwin emulation layer). Only the select() connection processing method is currently used, so high performance and scalability should not be expected. Due to this and some other known issues version of nginx for Windows is considered to be a beta version.他们还说了，以后我们会支持I/O completion port使得Windows版本的性能提高的。
nginx使用epoll事件模型，得益于此，nginx在Linux操作系统下效率相当高。同时Nginx在OpenBSD或FreeBSD操作系统上采用类似于epoll的高效事件模型kqueue。
Unix下5中I/O模型
（1）阻塞I/O
（2）非阻塞I/O
（3）I/O复用（select和poll）
（4）信号驱动I/O（SIGIO）
（5）异步I/O
阻塞I/O
最流行的I/O模型是阻塞I/O(blocking I/O）模型。缺省情况下，所有套接口都是阻塞的。
进程调用recvfrom，其系统调用直到数据报到达且被拷贝到应用进程的缓冲区中或者发生错误才返回。最常见的错误是系统调用被信号中断。我们说进程在从调用recvfrom开始到它返回的整段时间内是被阻塞的。recvfrom成功返回后，应用进程开始处理数据。
非阻塞I/O
进程把一个套接口设置成非阻塞是在通知内核：当所请求的I/O操作非得把本进程投入睡眠才能完成时，不要把本进程投入睡眠，而是返回一个错误。下图展示了非阻塞I/O模型。
前三次调用recvfrom时没有数据可返回，因此内核转而立即返回一个EWOULDBLOCK错误。第四次调用recvfrom时已有数据报准备好，它被拷贝到应用进程缓冲区，recvfrom于是成功返回。我们接着处理数据。
当一个应用进程像这样对一个非阻塞描述字循环调用recvfrom时，我们称之为轮询（polling）。应用进程持续轮询内核，以查看某个操作是否就绪。这么做往往耗费大量CPU时间，不过这种模型偶尔也会遇到，通常是在只专门提供某种功能的系统中才有。
I/O复用（select和poll）
有了I/O复用（I/O multiplexing），我们就可以调用select或poll，阻塞在这两个系统调用中的某一个之上，而不是阻塞在真正的I/O系统调用上。下图展示了I/O复用模型。
我们阻塞于select调用，等待数据报套接口变为可读。当select返回套接口可读这一条件时，我们调用recvfrom把所读数据报拷贝到应用进程缓冲区。
比较I/O复用模型和阻塞I/O模型，I/O复用并没有显示出什么优势，事实上由于使用select需要使用两个而不是单个系统调用，I/O复用还稍有劣势。使用select的优势在于我们可以等待多个描述字就绪。
与I/O复用密切相关的另一种I/O模型是在多线程中使用阻塞I/O。这种模型与I/O复用模型极为相似，代替使用select阻塞在多个文件描述字上的是，使用多个线程（每个文件描述字一个线程），这样每个线程都可以自由地调用诸如recvfrom之类的阻塞式I/O系统调用了。
信号驱动I/O模型
我们也可以用信号，让内核在描述字就绪时发送SIGIO信号通知我们。我们称这种模型为信号驱动I/O（signal-driven I/O），如下图所示：
我们首先开启套接口的信号驱动I/O功能，并通过sigaction系统调用安装一个信号处理函数。该系统调用立即返回，我们的进程继续工作，也就是说它没有被阻塞。当数据报准备好读取时，内核就为该进程产生一个SIGIO信号。我们随后既可以在信号处理函数中调用recvfrom读取数据报，并通知主循环数据已准备好待处理，也可以立即通知主循环，让它读取数据报。
无论如何处理SIGIO信号，这种模型的优势在于等待数据报到达期间，进程不被阻塞。主循环可以继续执行，只要不时等待来自信号处理函数的通知：既可以是数据已准备好被处理，也可以是数据报已准备好被读取。
异步I/O模型
异步I/O（asynchronous I/O）由POSIX规范定义。一般地说，这些函数的工作机制是：告知内核启动某个操作，并让内核在整个操作（包括将数据从内核拷贝到我们自己的缓冲区）完成后通知我们。这种模型与信号驱动模型的主要区别在于：信号驱动I/O是由内核通知我们何时启动一个I/O操作，而异步I/O模型是由内核通知我们I/O操作何时完成。
我们调用aio_read函数（POSIX异步I/O函数以aio_或lio_开头），给内核传递描述字、缓冲区指针、缓冲区大小（与read相同的三个参数）、文件偏移（与lseek类似），并告诉内核当整个操作完成时如何通知我们。该系统调用立即返回，在等待I/O完成期间，我们的进程不被阻塞。
各种I/O模型的比较
I/O多路复用之select，poll，epoll详解
select，poll，epoll都是IO多路复用的机制。I/O多路复用就是通过一种机制，一个进程可以监视多个描述符，一旦某个描述符就绪（一般是读就绪或者写就绪），能够通知程序进行相应的读写操作。但select，poll，epoll本质上都是同步I/O，因为他们都需要在读写事件就绪后自己负责进行读写，也就是说这个读写过程是阻塞的，而异步I/O则无需自己负责进行读写，异步I/O的实现会负责把数据从内核拷贝到用户空间。（这里啰嗦下）
select
int select (int n, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *timeout);
select 函数监视的文件描述符分3类，分别是writefds、readfds、和exceptfds。调用后select函数会阻塞，直到有描述副就绪（有数据 可读、可写、或者有except），或者超时（timeout指定等待时间，如果立即返回设为null即可），函数返回。当select函数返回后，可以 通过遍历fdset，来找到就绪的描述符。
select目前几乎在所有的平台上支持，其良好跨平台支持也是它的一个优点。select的一 个缺点在于单个进程能够监视的文件描述符的数量存在最大限制，在Linux上一般为1024，可以通过修改宏定义甚至重新编译内核的方式提升这一限制，但 是这样也会造成效率的降低。
poll
int poll (struct pollfd *fds, unsigned int nfds, int timeout);
不同与select使用三个位图来表示三个fdset的方式，poll使用一个 pollfd的指针实现。
struct pollfd {
int fd; /* file descriptor */
short events; /* requested events to watch */
short revents; /* returned events witnessed */
};
pollfd结构包含了要监视的event和发生的event，不再使用select“参数-值”传递的方式。同时，pollfd并没有最大数量限制（但是数量过大后性能也是会下降）。 和select函数一样，poll返回后，需要轮询pollfd来获取就绪的描述符。
从上面看，select和poll都需要在返回后，通过遍历文件描述符来获取已经就绪的socket。事实上，同时连接的大量客户端在一时刻可能只有很少的处于就绪状态，因此随着监视的描述符数量的增长，其效率也会线性下降。
epoll
epoll操作过程需要三个接口，分别如下：
int epoll_create(int size)；//创建一个epoll的句柄，size用来告诉内核这个监听的数目一共有多大
int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event)；
int epoll_wait(int epfd, struct epoll_event * events, int maxevents, int timeout);
int epoll_create(int size);
创建一个epoll的句柄，size用来告诉内核这个监听的数目一共有多大，这个参数不同于select()中的第一个参数，给出最大监听的fd+1的值，参数size并不是限制了epoll所能监听的描述符最大个数，只是对内核初始分配内部数据结构的一个建议。
当创建好epoll句柄后，它就会占用一个fd值，在linux下如果查看/proc/进程id/fd/，是能够看到这个fd的，所以在使用完epoll后，必须调用close()关闭，否则可能导致fd被耗尽。int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event)；
函数是对指定描述符fd执行op操作。epfd：是epoll_create()的返回值。
op：表示op操作，用三个宏来表示：添加EPOLL_CTL_ADD，删除EPOLL_CTL_DEL，修改EPOLL_CTL_MOD。分别添加、删除和修改对fd的监听事件。
fd：是需要监听的fd（文件描述符）
epoll_event：是告诉内核需要监听什么事，struct epoll_event结构如下：
struct epoll_event {
__uint32_t events; /* Epoll events */
epoll_data_t data; /* User data variable */
};
//events可以是以下几个宏的集合：
EPOLLIN ：表示对应的文件描述符可以读（包括对端SOCKET正常关闭）；
EPOLLOUT：表示对应的文件描述符可以写；
EPOLLPRI：表示对应的文件描述符有紧急的数据可读（这里应该表示有带外数据到来）；
EPOLLERR：表示对应的文件描述符发生错误；
EPOLLHUP：表示对应的文件描述符被挂断；
EPOLLET： 将EPOLL设为边缘触发(Edge Triggered)模式，这是相对于水平触发(Level Triggered)来说的。
EPOLLONESHOT：只监听一次事件，当监听完这次事件之后，如果还需要继续监听这个socket的话，需要再次把这个socket加入到EPOLL队列里
int epoll_wait(int epfd, struct epoll_event * events, int maxevents, int timeout);
等待epfd上的io事件，最多返回maxevents个事件。
参数events用来从内核得到事件的集合，maxevents告之内核这个events有多大，这个maxevents的值不能大于创建epoll_create()时的size，参数timeout是超时时间（毫秒，0会立即返回，-1将不确定，也有说法说是永久阻塞）。该函数返回需要处理的事件数目，如返回0表示已超时。
工作模式
epoll对文件描述符的操作有两种模式：LT（level trigger）和ET（edge trigger）。LT模式是默认模式，LT模式与ET模式的区别如下：
LT模式：当epoll_wait检测到描述符事件发生并将此事件通知应用程序，应用程序可以不立即处理该事件。下次调用epoll_wait时，会再次响应应用程序并通知此事件。
ET模式：当epoll_wait检测到描述符事件发生并将此事件通知应用程序，应用程序必须立即处理该事件。如果不处理，下次调用epoll_wait时，不会再次响应应用程序并通知此事件。
Java NIO简介
buffer
channel
selector
网络服务器模型
单线程阻塞I/O模型
多线程阻塞I/O模型
单线程非阻塞I/O模型（包括非阻塞I/O,I/O复用）
单线程异步I/O模型
单线程阻塞I/O模型
最简单的模型，计算机网络发展早期使用的解决方案。也是我们学习网络编程时首先接触的例子。它使用循环的方式，遍历处理所有的连接。这种方式的问题显而易见，随着连接数的增加，低效又缓慢。
多线程阻塞I/O模型
这是利用多线程对 单线程阻塞I/O模型 的改进，每个线程负责监听处理一个连接。随之而来的问题是，开启销毁线程的高昂代价：线程栈对内存的需求，线程切换对CPU的需求，频繁线程切换造成的不稳定（线程抖动）。
单线程非阻塞I/O模型（包括非阻塞I/O,I/O复用）
与 单线程阻塞I/O模型 类似，循环遍历处理所有连接。只是由于非阻塞I/O的特点，内核没有可用数据时立即返回，不会阻塞线程。这样的循环轮询容易大幅度推高CPU的占用率，因此一般我们不会使用这种方式，而是引入I/O复用，当没有可用数据时将线程阻塞在代理（select/poll/epoll）调用上，占用较少的CPU资源。
单线程异步I/O模型
总结
在单线程非阻塞I/O模型下，对于I/O密集型应用和计算（CPU）密集型应用，可以有不同的处理方式。对于I/O密集型应用，直接在循环监听线程中处理即可（Node.js/Tornado）；对于计算（CPU）密集型应用，则（选择）使用多线程/进程来处理就绪的连接，避免阻塞线程对连接的监听（术语叫event based，Nginx/Apache Event模式）。
结合开源软件讨论I/O策略
tomcat的I/O模型
Tomcat默认是BIO方式运行，如果想要换成NIO，可以配置server.xml：
<Connector port="8080" protocol="org.apache.coyote.http11.Http11NioProtocol" .../>
从性能上考虑建议使用NIO。
redis的I/O模型
单线程 epoll
memcache的I/O模型
多线程 基于libevent(封装epoll，kequeue等io模型)
netty的I/O模型
多线程 epoll
nginx的I/O模型
多进程+epoll(unix) select(win) kqueue(freebsd)