1. Unix IO模型

编程语言的IO实现依赖于底层操作系统，语言只是进行了上层封装。在Unix内核中，IO操作通常包括两个阶段:

• 等待数据准备好

• 从内核向进程复制数据

  • 内核中又会涉及用户态和内核态（kernel），这两部分数据是不能直接共享的，需要进行多次拷贝

    1.1 五大IO模型

    阻塞式 I/O

• 在IO进行的过程中，应用进程会被阻塞，直到数据复制到应用进程缓冲区中才返回。 注意，在阻塞的过程中，其它程序还可以执行，因此阻塞针对的是当前进程，而不是系统其他进程，因此其他程序还可以执行。由于不消耗 CPU 时间，这种模型的执行效率会比较高。

非阻塞式 I/O

• 应用进程执行系统调用之后，内核返回一个错误码。应用进程可以继续执行，但是需要不断的执行系统调用来获知 I/O 是否完成，这种方式称为轮询（polling），其实和自旋是一个道理。 由于 CPU 要处理更多的系统调用，因此这种模型是比较低效的。

I/O 复用（事件驱动）

• 使用内核函数 select 或者 poll 等待数据，并且可以等待多个套接字中的任何一个变为可读，这一过程会被阻塞，当某一个套接字可读时返回。之后再使用 recvfrom 把数据从内核复制到进程中。 它可以让单个进程具有处理多个 I/O 事件的能力。又被称为 Event Driven I/O，即事件驱动 I/O。
• 如果一个 Web 服务器没有 I/O 复用，那么每一个 Socket 连接都需要创建一个线程去处理。如果同时有几万个连接，那么就需要创建相同数量的线程。并且相比于多进程和多线程技术，I/O 复用不需要创建额外的进程或线程，也没有上下文切换的问题，系统开销更小。

信号驱动 I/O

• 应用进程使用 sigaction 系统调用，内核立即返回，应用进程可以继续执行，也就是说在等待数据的阶段应用进程是非阻塞的，可以去执行其他不需要IO返回的任务。
• 内核会在数据到达时向应用进程发送 SIGIO 信号，应用进程收到之后在信号处理程序中调用 recvfrom 将数据从内核复制到应用进程中。
• 相比于非阻塞式 I/O 的轮询方式，信号驱动 I/O 的 CPU 利用率更高。二者区别也很明显，前者是程序主动查，后者是内核主动通知。

异步 I/O

• 进行 aio_read 系统调用会立即返回，应用进程继续执行，不会被阻塞，内核会在所有操作完成之后向应用进程发送信号。
• 异步 I/O 与信号驱动 I/O 的区别在于，异步 I/O 的信号是通知应用进程 I/O 完成，而信号驱动 I/O 的信号是通知应用进程可以开始 I/O，前者通知后应用只需要取数据即可，后者通知后还需要参与IO复制的过程。

1.2 模型比较

阻塞和非阻塞IO

这两个概念是程序级别的。主要描述的是程序请求操作系统IO操作后，如果IO资源没有准备好，那么程序该如何处理的问题: 前者等待；后者继续执行(并且使用线程一直轮询，直到有IO资源准备好了)

同步与异步 I/O

这两个概念是操作系统级别的。主要描述的是操作系统在收到程序请求IO操作后，如果IO资源没有准备好，该如何相应程序的问题：前者不响应，直到IO资源准备好以后；后者返回一个标记（好让程序和自己知道以后的数据往哪里通知和取出），当IO资源准备好以后，再用事件机制返回给程序。

• 同步 I/O：应用进程在调用 recvfrom 操作时会阻塞。
• 异步 I/O：不会阻塞。

阻塞式 I/O、非阻塞式 I/O、I/O 复用和信号驱动 I/O 都是同步 I/O，虽然非阻塞式 I/O 和信号驱动 I/O 在等待数据阶段不会阻塞，但是在之后的将数据从内核复制到应用进程这个操作会阻塞。而异步I/O则不需要参与数据的复制工作，因此不会阻塞。

五大 I/O 模型比较

前四种 I/O 模型的主要区别在于第一个阶段，而第二个阶段是一样的: 将数据从内核复制到应用进程过程中，应用进程会被阻塞。

1.3 IO多路复用

多路复用被称为epoll，其描述符事件有两种触发模式：LT(level trigger)和 ET(edge trigger)。
著作权归https://www.pdai.tech所有。 链接：https://www.pdai.tech/md/java/io/java-io-model.html

LT 模式

当 epoll_wait() 检测到描述符事件到达时，将此事件通知进程，进程可以不立即处理该事件，下次调用 epoll_wait() 会再次通知进程。是默认的一种模式，并且同时支持 Blocking 和 No-Blocking。

ET 模式

和 LT 模式不同的是，通知之后进程必须立即处理事件，下次再调用 epoll_wait() 时不会再得到事件到达的通知。
很大程度上减少了 epoll 事件被重复触发的次数，因此效率要比 LT 模式高。只支持 No-Blocking，以避免由于一个文件句柄的阻塞读/阻塞写操作把处理多个文件描述符的任务饿死。

1.4 三种内核函数的对比

文件描述符

• 文件描述符是一个简单的整数，用以标明每一个被进程所打开的文件和socket。第一个打开的文件是0，第二个是1，第三个文件是2，依此类推。

• 文件描述符（file descriptor）是内核为了高效管理已被打开的文件所创建的索引，其是一个非负整数（通常是小整数），用于指代被打开的文件，所有执行I/O操作的系统调用都通过文件描述符。程序刚刚启动的时候，0是标准输入，1是标准输出，2是标准错误。如果此时去打开一个新的文件，它的文件描述符会是3，接下来是4，以此类推。

  select 应用场景

• select 的 timeout 参数精度为 1ns，而 poll 和 epoll 为 1ms，因此 select 更加适用于实时要求更高的场景，比如核反应堆的控制。

• select 可移植性更好，几乎被所有主流平台所支持。

  poll 应用场景

• poll 没有最大描述符数量的限制，如果平台支持并且对实时性要求不高，应该使用 poll 而不是 select。

• 需要同时监控的描述符小于 1000 个时就没有必要使用 epoll，因为这个应用场景下并不能体现 epoll 的优势。

• 需要监控的描述符状态变化多，而且都是非常短暂的，也没有必要使用 epoll。因为 epoll 中的所有描述符都存储在内核中，所以每次需要对描述符的状态改变都会通过 epoll_ctl() 进行系统调用，频繁系统调用降低效率。并且epoll 的描述符存储在内核，不容易调试。

  epoll 应用场景

• 程序只运行在 Linux 平台上，并且有非常大量的描述符需要同时轮询，而且这些连接最好都是长连接。

  2. BIO(blocking IO)

  JDK1.4之前的IO包使用了BIO模型，这是最容易理解、最容易实现的IO工作方式，应用程序向操作系统请求网络IO操作，这时应用程序会一直等待；另一方面，操作系统收到请求后，也会等待，直到网络上有数据传到监听端口；操作系统在收集数据后，会把数据发送给应用程序；最后应用程序受到数据，并解除等待状态。

  2.1 传统BIO模型

  以前大多数网络通信方式都是阻塞模式的，即:

• 客户端向服务器端发出请求后，客户端会一直等待(不会再做其他事情)，直到服务器端返回结果或者网络出现问题。

• 服务器端同样的，当在处理某个客户端A发来的请求时，另一个客户端B发来的请求会等待，直到服务器端的这个处理线程完成上一个处理。

传统的BIO的问题

• 同一时间，服务器只能接受来自于客户端A的请求信息；虽然客户端A和客户端B的请求是同时进行的，但客户端B发送的请求信息只能等到服务器接受完A的请求数据后，才能被接受。
• 由于服务器一次只能处理一个客户端请求，当处理完成并返回后(或者异常时)，才能进行第二次请求的处理。很显然，这样的处理方式在高并发的情况下，是不能采用的。

著作权归https://www.pdai.tech所有。 链接：https://www.pdai.tech/md/java/io/java-io-bio.html

2.2 多线程方式（伪异步）

上面说的情况是服务器只有一个线程的情况，那么有一个思路就是我们可以使用多线程技术来解决这个问题:

• 当服务器收到客户端X的请求后，(读取到所有请求数据后)将这个请求送入一个独立线程进行处理，然后主线程继续接受客户端Y的请求。
• 客户端一侧，也可以使用一个子线程和服务器端进行通信。这样客户端主线程的其他工作就不受影响了，当服务器端有响应信息的时候再由这个子线程通过 监听模式/观察模式(等其他设计模式)通知主线程。

仍旧存在问题

但是使用线程来解决这个问题实际上是有局限性的:

• 虽然在服务器端，请求的处理交给了一个独立线程进行，但是操作系统通知accept()的方式还是单个的。也就是，实际上是服务器接收到数据报文后的“业务处理过程”可以多线程，但是数据报文的接受还是需要一个一个的来。
• 在linux系统中，可以创建的线程是有限的。我们可以通过cat /proc/sys/kernel/threads-max 命令查看可以创建的最大线程数。当然这个值是可以更改的，但是线程越多，CPU切换所需的时间也就越长，用来处理真正业务的需求也就越少。
• 创建一个线程是有较大的资源消耗的。JVM创建一个线程的时候，即使这个线程不做任何的工作，JVM都会分配一个堆栈空间。这个空间的大小默认为128K，您可以通过-Xss参数进行调整。当然还可以使用ThreadPoolExecutor线程池来缓解线程的创建问题，但是又会造成BlockingQueue积压任务的持续增加，同样消耗了大量资源。
• 另外，如果应用程序大量使用长连接的话，线程是不会关闭的。这样系统资源的消耗更容易失控。

• 因此，BIO的根本问题不在于线程多少，而在于IO流从开始处理到返回的过程为什么会被阻塞。

  3. NIO(non-blocking IO)

  NIO库是在 JDK 1.4 中引入的，弥补了原来的 I/O 的不足，提供了高速的、面向块的 I/O，从名字也可以看出，这是一个非阻塞的IO模型。

  3.1 核心概念

  流与块

• I/O 与 NIO 最重要的区别是数据打包和传输的方式，I/O 以流的方式处理数据，而 NIO 以块的方式处理数据。

• 面向流的 I/O 一次处理一个字节数据：一个输入流产生一个字节数据，一个输出流消费一个字节数据。为流式数据创建过滤器非常容易，链接几个过滤器，以便每个过滤器只负责复杂处理机制的一部分。不利的一面是，面向流的 I/O 通常相当慢。
• 面向块的 I/O 一次处理一个数据块，按块处理数据比按流处理数据要快得多。但是面向块的 I/O 缺少一些面向流的 I/O 所具有的优雅性和简单性。

• java.io.* 包已经以 NIO 为基础重新实现了，所以现在它可以利用 NIO 的一些特性。

  通道

  通道 Channel 是对原 I/O 包中的流的模拟，可以通过它读取和写入数据。
  通道与流的不同之处在于，流只能在一个方向上移动（一个流必须是 InputStream 或者 OutputStream 的子类），而通道是双向的，可以用于读、写或者同时用于读写。
  通道包括以下类型：

• FileChannel：从文件中读写数据；

• DatagramChanne：通过 UDP 读写网络中数据；
• SocketChannel：通过 TCP 读写网络中数据；

• ServerSocketChannel：可以监听新进来的 TCP 连接，对每一个新进来的连接都会创建一个 SocketChannel。

  缓冲区

  发送给一个通道的所有数据都必须首先放到缓冲区中，同样地，从通道中读取的任何数据都要先读到缓冲区中。也就是说，不会直接对通道进行读写数据，而是要先经过缓冲区。
  缓冲区实质上是一个数组，但它不仅仅是一个数组。缓冲区提供了对数据的结构化访问，而且还可以跟踪系统的读/写进程。
  缓冲区包括以下类型:

• ByteBuffer

• CharBuffer
• ShortBuffer
• IntBuffer
• LongBuffer
• FloatBuffer
• DoubleBuffe

著作权归https://www.pdai.tech所有。 链接：https://www.pdai.tech/md/java/io/java-io-nio.html

选择器

• NIO 常常被叫做非阻塞 IO，主要是因为 NIO 在网络通信中的非阻塞特性被广泛使用。
• NIO 实现了 IO 多路复用中的 Reactor 模型，一个线程 Thread 使用一个选择器 Selector 通过轮询的方式去监听多个通道 Channel 上的事件，从而让一个线程就可以处理多个事件。
• 通过配置监听的通道 Channel 为非阻塞，那么当 Channel 上的 IO 事件还未到达时，就不会进入阻塞状态一直等待，而是继续轮询其它 Channel，找到 IO 事件已经到达的 Channel 执行。
• 因为创建和切换线程的开销很大，因此使用一个线程来处理多个事件而不是一个线程处理一个事件具有更好的性能。
• 应该注意的是，只有套接字 Channel 才能配置为非阻塞，而 FileChannel 不能，为 FileChannel 配置非阻塞也没有意义。

3.2 IO多路复用

典型的多路复用IO实现

目前流程的多路复用IO实现主要包括四种: select、poll、epoll、kqueue。下表是他们的一些重要特性的比较：

多路复用IO技术最适用的是“高并发”场景，所谓高并发是指1毫秒内至少同时有上千个连接请求准备好。其他情况下多路复用IO技术发挥不出来它的优势。另一方面，使用JAVA NIO进行功能实现，相对于传统的Socket套接字实现要复杂一些，所以实际应用中，需要根据自己的业务需求进行技术选择。

Reactor模型

Java对多路复用IO的支持如下：

重要概念: Channel

通道，是一个应用程序和操作系统交互事件、传递内容的渠道。一个通道会有一个专属的文件状态描述符。那么既然是和操作系统进行内容的传递，那么说明应用程序可以通过通道读取数据，也可以通过通道向操作系统写数据。

在Java中，所有被Selector（选择器）注册的通道，只能是SelectableChannel类的子类，有三个较常用的子类：

• ServerSocketChannel：应用服务器程序的监听通道。只有通过这个通道，应用程序才能向操作系统注册支持“多路复用IO”的端口监听。同时支持UDP协议和TCP协议。
• ScoketChanne：TCP Socket套接字的监听通道，一个Socket套接字对应了一个 客户端 IP:port 到 服务器 IP:port 的通信连接。
• DatagramChannel：UDP 数据报文的监听通道。

  重要概念: Buffer

  数据缓存区：在JAVA NIO 框架中，为了保证每个通道的数据读写速度，JAVA NIO 框架为每一种需要支持数据读写的通道集成了Buffer的支持。

每集成buffer的通道不具备数据读写能力，例如ServerSocketChannel通道它只支持对OP_ACCEPT事件的监听，所以它是不能直接进行网络数据内容的读写的（ServerSocketChannel是没有集成Buffer的，因此不具备数据读写的能力）。

Buffer有两种工作模式：写模式和读模式。在读模式下，应用程序只能从Buffer中读取数据，不能进行写操作。但是在写模式下，应用程序是可以进行读操作的，这就表示可能会出现脏读的情况。所以在从Buffer中读取数据前，一定要将Buffer的状态改为读模式。

重要概念: Selector

Selector的英文含义是“选择器”，不过根据其岗位职责，我们可以把它称之为“轮询代理器”、“事件订阅器”、“channel容器管理机”等。

• 事件订阅和Channel管理

应用程序将向Selector对象注册需要它关注的Channel，以及具体的某一个Channel会对哪些IO事件感兴趣。Selector中也会维护一个“已经注册的Channel”的容器。以下代码来自WindowsSelectorImpl实现类中，对已经注册的Channel的管理容器:

• 轮询代理

应用层不再通过阻塞模式或者非阻塞模式直接询问操作系统“事件有没有发生”，而是由Selector代其询问。

• 实现不同操作系统的支持

之前已经提到过，多路复用IO技术 是需要操作系统进行支持的，其特点就是操作系统可以同时扫描同一个端口上不同网络连接的事件。所以作为上层的JVM，必须要为不同操作系统的多路复用IO实现 编写不同的代码。
例如Windows系统下，对应的实现类就是sun.nio.ch.WindowsSelectorImpl

优缺点

• 在IO处理过程中不需要再借助多线程了（相对操作系统内核IO管理模块和应用程序进程而言），业务代码就可以放心使用线程。
• 同一个端口可以处理多种协议，例如，使用ServerSocketChannel实现的服务器端口监听，既可以处理TCP协议又可以处理UDP协议。
• 操作系统级别的优化: 多路复用IO技术可以是操作系统级别在一个端口上能够同时接受多个客户端的IO事件。同时具有之前我们讲到的阻塞式同步IO和非阻塞式同步IO的所有特点。Selector的一部分作用更相当于“轮询代理器”。

• 都是同步IO: 目前我们介绍的 阻塞式IO、非阻塞式IO甚至包括多路复用IO，这些都是基于操作系统级别对“同步IO”的实现。我们一直在说“同步IO”，一直都没有详细说，什么叫做“同步IO”。实际上一句话就可以说清楚: 只有上层（包括上层的某种代理机制)）系统询问我是否有某个事件发生了，否则我不会主动告诉上层系统事件发生了

  4. 异步-AIO

• 现在，我们知道了Java的IO模型演进路线，从传统BIO（阻塞式同步IO），到NIO（非阻塞式同步IO、多路复用IO ），但这三种IO模型仍旧属于同步IO，都是采用的“应用程序不询问我，我绝不会主动通知”的方式。

• 异步IO则是采用“订阅-通知”模式：即应用程序向操作系统注册IO监听，然后继续做自己的事情。当操作系统发生IO事件，并且准备好数据后，在主动通知应用程序，触发相应的函数：

• 和同步IO一样，异步IO也是由操作系统进行支持的。微软的windows系统提供了一种真正意义上的异步IO技术：IOCP（I/O Completion Port，I/O完成端口）；
• Linux下由于没有这种异步IO技术，所以使用的是epol（即多路复用IO技术的实现）模拟异步IO。
• JAVA AIO框架在windows下使用windows IOCP技术，在Linux下使用epoll多路复用IO技术模拟异步IO

  4.1 核心思想

  在JAVA NIO框架中，我们说到了一个重要概念“selector”(选择器)。它负责代替应用查询中所有已注册的通道到操作系统中进行IO事件轮询、管理当前注册的通道集合，定位发生事件的通道等操操作；但是在JAVA AIO框架中，由于应用程序不是“轮询”方式，而是订阅-通知方式，所以不再需要“selector”(选择器)了，改由channel通道直接到操作系统注册监听。

JAVA AIO框架中，只实现了两种网络IO通道“AsynchronousServerSocketChannel”(服务器监听通道)、“AsynchronousSocketChannel”(socket套接字通道)。但是无论哪种通道他们都有独立的fileDescriptor(文件标识符)、attachment(附件，附件可以使任意对象，类似“通道上下文”)，并被独立的SocketChannelReadHandle类实例引用。

4.2 Netty-高性能IO框架

为什么需要Netty？

虽然Java底层已经实现了完整的NIO和AIO，但Netty的出现还是很有必要的：

• 虽然JAVA NIO 和 JAVA AIO框架提供了 多路复用IO/异步IO的支持，但是并没有提供上层“信息格式”的良好封装。例如前两者并没有提供针对 Protocol Buffer、JSON这些信息格式的封装，但是Netty框架提供了这些数据格式封装（基于责任链模式的编码和解码功能）。
  
• 要编写一个可靠的、易维护的、高性能的（注意排序）NIO/AIO 服务器应用。除了框架本身要兼容实现各类操作系统的实现外。更重要的是它应该还要处理很多上层特有服务，例如: 客户端的权限、还有上面提到的信息格式封装、简单的数据读取。这些Netty框架都提供了支持。
  

• JAVA NIO框架存在一个poll/epoll bug：Selector doesn’t block on Selector.select(timeout)，不能block意味着CPU的使用率会变成100%（这是底层JNI的问题）。当然这个bug只有在Linux内核上才能重现。虽然Netty 4.0中也是基于JAVA NIO框架进行封装的，但是Netty已经将这个bug进行了处理。

  Netty的优势

• api简单，开发门槛低

• 功能强大，内置了多种编码、解码功能
• 与其它业界主流的NIO框架对比，netty的综合性能最优
• 社区活跃，使用广泛，经历过很多商业应用项目的考验
• 定制能力强，可以对框架进行灵活的扩展

  5. Java实现零拷贝思想

  关于零拷贝思想的原理，请点击查看，Java NIO 对零拷贝的实现，主要包括基于内存映射（mmap）方式的 MappedByteBuffer 以及基于 sendfile 方式的 FileChannel。

在 Java NIO 中的通道(Channel)就相当于操作系统的内核空间(kernel space)的缓冲区，而缓冲区(Buffer)对应的相当于操作系统的用户空间（user space）中的用户缓冲区（user buffer）。

• 通道（Channel）是全双工的（双向传输），它既可能是读/写缓冲区（read/write buffer），也可能是网络缓冲区（socket buffer）。
• 缓冲区（Buffer）分为堆内存（HeapBuffer）和堆外内存（DirectBuffer），这是通过 malloc() 函数分配出来的用户态内存。

堆外内存（DirectBuffer）在使用后需要应用程序手动回收，而堆内存（HeapBuffer）的数据在 GC 时可能会被自动回收。因此，在使用 HeapBuffer 读写数据时，为了避免缓冲区数据因为 GC 而丢失，NIO 会先把 HeapBuffer 内部的数据拷贝到一个临时的 DirectBuffer 中的本地内存（native memory），这个拷贝涉及到 sun.misc.Unsafe.copyMemory() 的调用，背后的实现原理与 memcpy() 类似。 最后，将临时生成的 DirectBuffer 内部的数据的内存地址传给 I/O 调用函数，这样就避免了再去访问 Java 对象处理 I/O 读写。

Netty零拷贝实现

Netty 中的零拷贝和上面提到的操作系统层面上的零拷贝不太一样, 我们所说的 Netty 零拷贝完全是基于（Java 层面）用户态的，它的更多的是偏向于数据操作优化这样的概念，具体表现在以下几个方面：

• Netty 通过 DefaultFileRegion 类对 java.nio.channels.FileChannel 的 tranferTo() 方法进行包装，在文件传输时可以将文件缓冲区的数据直接发送到目的通道（Channel）
• ByteBuf 可以通过 wrap 操作把字节数组、ByteBuf、ByteBuffer 包装成一个 ByteBuf 对象，进而避免了拷贝操作 ByteBuf 支持 slice 操作，因此可以将 ByteBuf 分解为多个共享同一个存储区域的 ByteBuf，避免了内存的拷贝 Netty 提供了 CompositeByteBuf 类，它可以将多个 ByteBuf 合并为一个逻辑上的 ByteBuf，避免了各个 ByteBuf 之间的拷贝
• 其中第 1 条属于操作系统层面的零拷贝操作，后面的只能算用户层面的数据操作优化。

著作权归https://www.pdai.tech所有。 链接：https://www.pdai.tech/md/java/io/java-io-nio-zerocopy.html

RocketMQ和Kafka对比

RocketMQ 选择了 mmap + write 这种零拷贝方式，适用于业务级消息这种小块文件的数据持久化和传输；而 Kafka 采用的是 sendfile 这种零拷贝方式，适用于系统日志消息这种高吞吐量的大块文件的数据持久化和传输。但是值得注意的一点是，Kafka 的索引文件使用的是 mmap + write 方式，数据文件使用的是 sendfile 方式。