I/O基础入门
Java1.4 之前的早期版本，Java对I/O的支持并不完善，开人员在开发高性能I/O程序时是有非常大的困难的,总结有以下几点:
- 没有数据缓存区，I/O性能存在问题
- 没有C或者C++中的Channel概念，只有输入和输出流
- 同步阻塞I/O通行(BIO)，通常会导致通信线程被长时间阻塞。
- 文件的字符集有限，硬件移值性不好
因为以上的一些缺陷,所以在很长的一段时间内，服务器端的开发领域一直被C++和C长期占据。
Linux 网络I/O模型简介
Linux的内核将所有的外部设备都看作一个文件来操作，对一个文件的读写操作会调用内核提供的系统命令，返回一个 file descriptor(fd, 文件描述符)。而对一个socket的读写也会有相应的描述符，称为 socketfd(socket 描述符)，描述符就是一个数字，它指向内核中的一个结构体(文件路径，数据区等属性)。
UNIX网络编程对I/O模型的分类，UNIX提供了5种I/O模型
- 阻塞IO模型(BIO)：最常用的I/O模型就是阻塞模型，缺省的情形下，所有的文件操作都是阻塞的。我们以套接字接口为例来讲解此模型:在进程空间中调用recvfrom，其系统调用直到数据包到达且被复制到应用进程的缓冲区或者发生错误的时候才返回，否则，在此期间一直会等待，进程在从调用recvfrom开始到它返回的整段时间都是被阻塞的，因此被称为阻塞I/O模型。 如下图：
- 非阻塞(NIO)： refcvfrom 从应用层到内核的时候，如果该缓冲区没有数据的话，就直接返回一个EWOULDBLOCK错误，一般来说非阻塞I/O模型进行轮寻检查这个状态，看内核是不是有数据到来.
- I/O复用模型：Linux 提供select/poll，进程通过将一个或多个fd传递给select 或poll系统调用，阻塞在select操作上，这样select/poll可以帮助我们侦测多个fd是否处于就绪状态，select/poll是顺序扫描fd是否就绪，而且支持的fd数量有限，因此它的使用受到一些限制，Linux还提供了一个epoll系统调用，epoll使用基于事件驱动方式代替顺序扫描，因此性能更高，当有fd准备就绪时，就立即回调函数rollback.如下图所示:
- 信号驱动I/O模型：首先开启套接口信号驱动I/O功能，并通过系统调用sigaction执行一个信号处理函数(此系统调用立即返回，进程继续工作，它是非阻塞的)。当数据准备就绪时，就为该进程生成一个SIGIO信号，通过信号回调通知应用程序调用recvfrom来读取数据，并通知主循环函数处理数据，如下图：
- 异步I/O：告知内核启动某个操作，并让内核在整个操作完成后(包括将数据从内核复制到用户自己的缓冲区)通知我们。这种模型与信号量驱动模型的主要区别是: 信号驱动I/O由内核通知我们何时可以开始一个I/O操作，异步Java NIO的核心类库多路复用器selector 就是基于 epoll 的多路复用技术实现。I/O模型由内核通知我们I/O已经完成。如下图：
I/O多路复用技术
在I/O编程过程中，当需要同时处理多个客户端接入请求时，可以利用多个线程或者I/O多路复用技术进行处理，I/O多路复用技术通过把多个I/O的阻塞复用到同一个select 的阻塞上，从而使得系统在单线程中可以同时处理多个客户端请求，与传统的多线程/多进程，模型比，I/O多路复用的最大优势是系统开销小，系统不需要创建新的额外进程或者线程，也不需要维护这些进程和线程的运行，降低了系统的维护工作量，节省了系统资源，I多路复用的主要应用场景如下：
- 服务器需要同时处理多个处于监听状态或者多个连接状态的套接字
- 服务器需要同时处理多种网络协议的套接字
目前支持I/O多路复用的系统调用有select、pselect、poll、epoll, 在Linux网络编程过程中，很长一段时间都使用select做轮询和网络事件通知，然而select的一些固有缺陷导致了它受到了很大的限制，最终Linux不得不在新的内核版本中寻找select的替代方案，最终选择了epoll与select的原理比较类似。
为了克服 select的缺点， epoll 做了很大的改进:
- 支持一个进程打开的socket描述符(FD)不受限制(仅受限于操作系统的最大文件句柄数。
select最大的缺陷就是单个进程锁打开的FD是有一定限制的，它由FD_SETSIZE设置，默认值是1024,对于那些需要支持上万个TCP连接的大型服务器来说显然太少了。可以选择修改这个宏然后重新编译内核，不过这会带来网络效率的下降。我们也可以通过选择多个进程的方案(传统的Apache 方案)解决这个问题，不过虽然在Linux上创建进程的代价比较小，但仍然是不可忽视的，另外，进程间的数据交换非常麻烦，对于java来说，由于没有共享内存，需要通过Socket通心或者其他方式进行数据同步，这带来了额外的性能损耗，增加了程序的复杂度，所以这也不是一个完美的解决方案。 但是值得庆幸的是， epoll并没有这个限制，它所支持的FD上限是操作系统的最大文件句柄数，这个数字远远大于1024.例如: 在1GB内存的机器上大约10万个文件句柄左右，具体的值可以通过cat /proc/sys/fs/file -max 查看，通常情况下这个值跟系统的内存关系比较大 - I/O效率不会随着FD数目的增加而线性下降。
传统 select/poll的另一个致命的弱点，就是当你拥有一个很大的socket 集合时，由于网络的延时或者链路空闲，任一时刻只有少部分的socket是”活跃”的,但是 select/poll 每次调用都会线性扫描全部的集合，导致效率呈现线性下降。epoll 不存在这个问题，它只会对”活跃”的socket 进行操作——这是因为在内核实现中，epoll 是根据每个fd上面的callback函数实现的。那么，只有”活跃”的socket 才会去主动调用callback函数，其他idle状态的socket则不会。在这点上，epoll实现了一个伪AIO. 针对 epoll和select性能对比的benchmark 测试表明: 如果所有的socket都处于活跃状态——例如一个高速LAN环境，epoll并不比select/poll 效率高太多；相反，如果过多使用epoll_ctl， 效率相比还有稍微地降低。但是一旦使用 idle connections 模拟WAN环境，epoll的效率就远在select/poll 之上了。 - 使用mmap加速内核与用户空间的消息传递。
无论是select、poll还是epoll都需要内核把FD消息通知给用户空间，如何避免不必要的内存复制就显得非常重要，epoll是通过内核和用户空间mmap同一块内存来实现的。 - epoll的API更加简单
Java的I/O演进
在JDK 1.4 推出Java NIO 之前，基于Java 的所有Socket 通信都采用同步阻塞模式(BIO)，这种一请求一问答的通信模型简化了上层的应用开发，但是在性能和可靠性方面却存在巨大的瓶颈。因此很长的一段时间里，大型的应用服务器都采用C 或者 C++ 语言开发，因为他们可以直接使用操作系统中的异步I/O或者AIO能力，当并发访问量增大、响应时间延迟增大之后，采用Java BIO开发的服务端软件只有通过硬件的不断扩容来满足高并发和低延时，它极大的增加了企业的成本，并且随着集群规模的不断膨胀，系统的可维护性也面临巨大的挑战，只有通过采购性能更好的硬件服务器来解决问题，这导致恶性的循环。
正是Java 传统的BIO的劣性，才使得Java 支持非阻塞I/O的呼声日渐个高涨，最终 JDK 1.4 中提供了新的NIO 类库，Java也可以支持非阻塞I/O了。
Java 的I/O 发展
JDK1.4 新增 java.nio 包，提供了很多进行异步I/O开发的API和类库，主要的类和接口如下：
- 进行异步I/O操作的缓冲区ByteBuffer等
- 进行异步I/O操作的管道Pipe
- 进行各种I/O操作(异步或者同步)的Channel，包括ServerSocketChannel和SocketChannel;
- 多种字符集的编码能力和解码能力;
- 实现非阻塞I/O操作的多路复用器selector;
- 基于流行的Perl实现的正则表达式类库;
- 基于流行的Perl 实现的正则表达式类库;
- 文件通道FileChannel
新的NIO类库的提供极大的促进基于Java 的异步非阻塞编程的发展和应用,但是，它依然有不完善的地方，特别是对文件系统的处理能力仍显得不足，主要的问题如下：
- 没有统一的文件属性(例如读写权限)
- API能力比较弱，例如目录的级联创建和递归遍历，往往需要自己实现
- 底层存储系统的一些高级API无法使用
- 所有的文件操作都是同步阻塞调用，不支持异步文件读写操作
2011 年 JDK1.7正式发布，它的一个比较大的亮点是将原来的NIO类库进行了升级，被称为 NIO2.0， 它主要有如下三个方面的改进：
- 提供能够批量获取文件属性的API，这些API具有平台无关性，不与特定的文件系统相耦合，另外它还提供了标准文件系统的SPI，供各个服务提供商扩展实现
- 提供AIO功能，支持基于文件的异步操作和针对网络套接字的异步操作
