Java Web基础篇之Java I/O

Java Web系列文章汇总贴: Java Web知识总结汇总

---

1、I/O基础

BIO

在JDK1.4出来之前，我们建立网络连接的时候采用BIO模式，需要先在服务端启动一个ServerSocket，然后在客户端启动Socket来对服务端进行通信，默认情况下服务端需要对每个请求建立一堆线程等待请求，而客户端发送请求后，先咨询服务端是否有线程相应，如果没有则会一直等待或者遭到拒绝请求，如果有的话，客户端会线程会等待请求结束后才继续执行。

NIO

NIO本身是基于事件驱动思想来完成的，其主要想解决的是BIO的大并发问题： 在使用同步I/O的网络应用中，如果要同时处理多个客户端请求，或是在客户端要同时和多个服务器进行通讯，就必须使用多线程来处理。也就是说，将每一个客户端请求分配给一个线程来单独处理。这样做虽然可以达到我们的要求，但同时又会带来另外一个问题。由于每创建一个线程，就要为这个线程分配一定的内存空间（也叫工作存储器），而且操作系统本身也对线程的总数有一定的限制。如果客户端的请求过多，服务端程序可能会因为不堪重负而拒绝客户端的请求，甚至服务器可能会因此而瘫痪。

NIO基于Reactor，当socket有流可读或可写入socket时，操作系统会相应的通知引用程序进行处理，应用再将流读取到缓冲区或写入操作系统。 也就是说，这个时候，已经不是一个连接就要对应一个处理线程了，而是有效的请求，对应一个线程，当连接没有数据时，是没有工作线程来处理的。

BIO与NIO一个比较重要的不同，是我们使用BIO的时候往往会引入多线程，每个连接一个单独的线程；而NIO则是使用单线程或者只使用少量的多线程，每个连接共用一个线程。

AIO

与NIO不同，当进行读写操作时，只须直接调用API的read或write方法即可。这两种方法均为异步的，对于读操作而言，当有流可读取时，操作系统会将可读的流传入read方法的缓冲区，并通知应用程序；对于写操作而言，当操作系统将write方法传递的流写入完毕时，操作系统主动通知应用程序。 即可以理解为，read/write方法都是异步的，完成后会主动调用回调函数。 在JDK1.7中，这部分内容被称作NIO.2，主要在java.nio.channels包下增加了下面四个异步通道：
AsynchronousSocketChannel
AsynchronousServerSocketChannel
AsynchronousFileChannel
AsynchronousDatagramChannel
其中的read/write方法，会返回一个带回调函数的对象，当执行完读取/写入操作后，直接调用回调函数。

BIO是一个连接一个线程。
NIO是一个请求一个线程。
AIO是一个有效请求一个线程。

参考：
JAVA BIO与NIO、AIO的区别
Java I/O基础之I/O模型分类&I/O多路复用技术
几种I/O编程实践
Java 网络IO编程总结
NIo、Bio、aio、 的原理及区别与应用场景

2、多路复用I/O

select、poll：在本质上没有多大差别，管理多个描述符也是进行轮询，根据描述符的状态进行处理，但是poll没有最大文件描述符数量的限制。poll和select同样存在一个缺点就是，包含大量文件描述符的数组被整体复制于用户态和内核的地址空间之间，而不论这些文件描述符是否就绪，它的开销随着文件描述符数量的增加而线性增大
epoll：是在2.6内核中提出的，是之前的select和poll的增强版本。相对于select和poll来说，epoll更加灵活，没有描述符限制。epoll使用一个文件描述符管理多个描述符，将用户关系的文件描述符的事件存放到内核的一个事件表中，这样在用户空间和内核空间的copy只需一次。
通过红黑树和双链表数据结构，并结合回调机制，造就了epoll的高效。
一句话描述就是：三步曲。
第一步：epoll_create()系统调用。此调用返回一个句柄，之后所有的使用都依靠这个句柄来标识。红黑树存储连接的socket(每个树节点上的事件挂上事件链表)。
第二步：epoll_ctl()系统调用。通过此调用向epoll对象中添加、删除、修改感兴趣的事件，返回0标识成功，返回-1表示失败。挂载一遍事件，加回调函数，有就绪事件就往链表里面加事件。
第三部：epoll_wait()系统调用。通过此调用收集收集在epoll监控中已经发生的事件。查看链表里面有无数据。

eopll的高效原因：

上边我们学习了epoll和select/poll的相关基础，并且比较了它们的区别，发现epoll性能高效，那我们需要思考，epoll高效的原因何在。
先总结一下：epoll通过mmap+红黑树+双链表+回调机制，造就了epoll 的高效。
epoll是通过内核与用户空间mmap同一块内存实现的。mmap将用户空间的一块地址和内核空间的一块地址同时映射到相同的一块物理内存地址（不管是用户空间还是内核空间都是虚拟地址，最终要通过地址映射映射到物理地址），使得这块物理内存对内核和对用户均可见，减少用户态和内核态之间的数据交换。内核可以直接看到epoll监听的句柄，效率高。
红黑树将存储epoll所监听的套接字。上面mmap出来的内存如何保存epoll所监听的套接字，必然也得有一套数据结构，epoll在实现上采用红黑树去存储所有套接字，当添加或者删除一个套接字时（epoll_ctl），都在红黑树上去处理，红黑树本身插入和删除性能比较好，时间复杂度O(logN)。
一个fd被添加到epoll中之后（调用epoll_ctl的epoll_ctl_add模式），内核会为其生成一个对应的epitem结构对象，然后epitem会被添加到红黑树中，红黑树的作用就是在添加、删除、修改fd时，能够快速实现。

添加以及返回事件

通过epoll_ctl函数添加进来的事件fd都会被放在红黑树的某个节点内，所以，重复添加是没有用的。
建立回调+回调的逻辑是将就绪事件fd加入到双向链表中，epoll_wait调用时只需判断链表是否为空即可。
当把事件fd添加进来的时候时候会完成关键的一步，那就是该事件（fd(socket+事件类型)）都会与相应的设备（网卡）驱动程序建立回调关系，当相应的事件发生后（O(1)就可判断事件是否发生），就会调用这个回调函数，该回调函数在内核中被称为：ep_poll_callback,这个回调函数的逻辑就是就所把这个事件添加到rdllist这个双向链表中。一旦有事件发生，epoll就会将该事件添加到双向链表中。那么当我们调用epoll_wait时，epoll_wait只需要检查rdlist双向链表中是否有存在注册的事件，效率非常可观。这里也需要将链表中就绪的事件复制到用户态内存中即可。

epoll_wait的工作流程：

epoll_wait调用ep_poll，当rdlist为空（无就绪fd）时挂起当前进程，直到rdlist不空时进程才被唤醒。
文件fd状态改变（buffer由不可读变为可读或由不可写变为可写），导致相应fd上的回调函数ep_poll_callback()被调用。
ep_poll_callback将相应fd对应epitem加入rdlist，导致rdlist不空，进程被唤醒，epoll_wait得以继续执行。
ep_events_transfer函数将rdlist中的epitem拷贝到txlist中，并将rdlist清空。
ep_send_events函数（很关键），它扫描txlist中的每个epitem，调用其关联fd对用的poll方法。此时对poll的调用仅仅是取得fd上较新的events（防止之前events被更新），之后将取得的events和相应的fd发送到用户空间（封装在struct epoll_event，从epoll_wait返回）。

摘自：
IO复用模式–select、poll、epoll详解

相关：
深度理解select、poll和epoll
select、poll、epoll、同步、异步之间的区别总结[整理]
教你初步了解红黑树
红黑树与二叉树、平衡二叉树对比

3、Netty

3.1、I/O复用模型

3.2、Reactor线程模型

Reactor 是反应堆的意思，Reactor 模型是指通过一个或多个输入同时传递给服务处理器的服务请求的事件驱动处理模式。

服务端程序处理传入多路请求，并将它们同步分派给请求对应的处理线程，Reactor 模式也叫 Dispatcher 模式，即 I/O 多了复用统一监听事件，收到事件后分发(Dispatch 给某进程)，是编写高性能网络服务器的必备技术之一。

Reactor 模型中有 2 个关键组成：

Reactor，Reactor 在一个单独的线程中运行，负责监听和分发事件，分发给适当的处理程序来对 IO 事件做出反应。它就像公司的电话接线员，它接听来自客户的电话并将线路转移到适当的联系人。
Handlers，处理程序执行 I/O 事件要完成的实际事件，类似于客户想要与之交谈的公司中的实际官员。Reactor 通过调度适当的处理程序来响应 I/O 事件，处理程序执行非阻塞操作。

3.3、Netty线程模型

3.4、Netty功能特性图

Netty 功能特性如下：

传输服务，支持 BIO 和 NIO。
容器集成，支持 OSGI、JBossMC、Spring、Guice 容器。
协议支持，HTTP、Protobuf、二进制、文本、WebSocket 等一系列常见协议都支持。还支持通过实行编码解码逻辑来实现自定义协议。
Core 核心，可扩展事件模型、通用通信 API、支持零拷贝的 ByteBuf 缓冲对象。

3.5、Netty Reactor工作架构图

参考：
Netty原理解析
Netty与Mina对比