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