BIO，NIO，直接内存，零拷贝

前置知识

什么是Socket？

Socket是应用层与TCP/IP协议族通信的中间软件抽象层，它是一组接口，一般由操作系统提供。在设计模式中，Socket其实就是一个门面模式，它把复杂的TCP/IP协议处理和通信缓存管理等等都隐藏在Socket接口后面，对用户来说，使用一组简单的接口就能进行网络应用编程，让Socket去组织数据，以符合指定的协议。主机 A 的应用程序要能和主机 B 的应用程序通信，必须通过 Socket 建立连接。

客户端连接上一个服务端，就会在客户端中产生一个socket接口实例，服务端每接受一个客户端连接，就会产生一个socket接口实例和客户端的socket进行通信，有多个客户端连接自然就有多个socket接口实例。

短连接

连接->传输数据->关闭连接传统HTTP是无状态的，浏览器和服务器每进行一次HTTP操作，就建立一次连接，但任务结束就中断连接。也可以这样说：短连接是指SOCKET连接后发送后接收完数据后马上断开连接。

长连接

连接->传输数据->保持连接 -> 传输数据-> 。。。 ->关闭连接。长连接指建立SOCKET连接后不管是否使用都保持连接。

什么时候用长连接，短连接？

长连接多用于操作频繁，点对点的通讯。每个TCP连接都需要三步握手，这需要时间，如果每个操作都是先连接，再操作的话那么处理速度会降低很多，所以每个操作完后都不断开，下次处理时直接发送数据包就OK了，不用建立TCP连接。例如：数据库的连接用长连接，如果用短连接频繁的通信会造成socket错误，而且频繁的socket 创建也是对资源的浪费。

而像WEB网站的http服务按照Http协议规范早期一般都用短链接，因为长连接对于服务端来说会耗费一定的资源，而像WEB网站这么频繁的成千上万甚至上亿客户端的连接用短连接会更省一些资源。但是现在的Http协议，Http1.1，尤其是Http2、Http3已经开始向长连接演化。

总之，长连接和短连接的选择要视情况而定。

前置故事

我们首先来看一个生活中的场景。坤坤准备开一个心理咨询中心，嘴上光喊没用，只有到工商局注册"IKUN心理诊所"并且在篮球公园888号挂牌了，才算正式开张。疫情来了，准备开展电话业务，申请了一个电话号码88888888。小黑子一号有了心理问题，于是打电话过来，坤坤接了电话，但是坤坤不懂心理咨询，于是通过内部分机把电话转给请来的心理医生A负责接待小黑子一号，心理医生A和小黑子一号通过电话进行沟通，模式一般就是一个人说另个一人听，两者进行沟通交流。小黑子二号也来了，坤坤接了电话，又把电话转给请来的心理医生B负责接待小黑子二号，心理医生B和小黑子二号也通过电话进行沟通。

上述的场景和网络编程有很大的相似之处。

我们已经知道在通信编程里提供服务的叫服务端，连接服务端使用服务的叫客户端。在开发过程中，如果类的名字有Server或者ServerSocket的，表示这个类是给服务端容纳网络服务用的，如果类的名字只包含Socket的，那么表示这是负责具体的网络读写的。

那么对于服务端来说ServerSocket就只是个场所，就像上面的"IKUN心理诊所"，它必须要绑定某个IP地址，就像"IKUN心理诊所"在"篮球公园888号挂牌"，同时ServerSocket还需要监听某个端口，就像"申请了一个电话号码88888888"。

有电话进来了，具体和客户端沟通的还是一个一个的socket，就像"坤坤不懂心理咨询，于是通过内部分机把电话转给请来的心理医生A负责接待小黑子一号"，所以在通信编程里，ServerSocket并不负责具体的网络读写，ServerSocket就只是负责接收客户端连接后，新启一个socket来和客户端进行沟通。这一点对所有模式的通信编程都是适用的。

在通信编程里，我们关注的其实也就是三个事情：连接（客户端连接服务器，服务器等待和接收连接）、读网络数据、写网络数据，所有模式的通信编程都是围绕着这三件事情进行的。服务端提供IP和监听端口，客户端通过连接操作想服务端监听的地址发起连接请求，通过三次握手连接，如果连接成功建立，双方就可以通过套接字进行通信。

我们后面将学习的BIO和NIO其实都是处理上面三件事，只是处理的方式不一样。

Java原生网络编程

原生JDK网络编程BIO

什么是BIO?

BIO，意为Blocking I/O，即阻塞的I/O

BIO基本上就是我们上面所说的生活场景的朴素实现。在BIO中类ServerSocket负责绑定IP地址，启动监听端口，等待客户连接；客户端Socket类的实例发起连接操作，ServerSocket接受连接后产生一个新的服务端socket实例负责和客户端socket实例通过输入和输出流进行通信。

BIO的阻塞体现在什么地方？

bio的阻塞，主要体现在两个地方。

①若一个服务器启动就绪，那么主线程就一直在等待着客户端的连接，这个等待过程中主线程就一直在阻塞。

②在连接建立之后，在读取到socket信息之前，线程也是一直在等待，一直处于阻塞的状态下的。

TODO实现代码

传统BIO通讯模型

传统BIO通信模型：采用BIO通信模型的服务端，通常由一个独立的Acceptor线程负责监听客户端的连接，它接收到客户端连接请求之后为每个客户端创建一个新的线程进行链路处理，处理完成后，通过输出流返回应答给客户端，线程销毁。即典型的一请求一应答模型，同时数据的读取写入也必须阻塞在一个线程内等待其完成。

该模型最大的问题就是缺乏弹性伸缩能力，当客户端并发访问量增加后，服务端的线程个数和客户端并发访问数呈1:1的正比关系，Java中的线程也是比较宝贵的系统资源，线程数量快速膨胀后，系统的性能将急剧下降，随着访问量的继续增大，系统最终就死-掉-了。

伪异步I/O模型

为了改进这种一连接一线程的模型，我们可以使用线程池来管理这些线程，实现1个或多个线程处理N个客户端的模型（但是底层还是使用的同步阻塞I/O），通常被称为"伪异步I/O模型"。

我们知道，如果使用CachedThreadPool线程池（不限制线程数量，如果不清楚请参考文首提供的文章），其实除了能自动帮我们管理线程（复用），看起来也就像是1:1的客户端：线程数模型，而使用FixedThreadPool我们就有效的控制了线程的最大数量，保证了系统有限的资源的控制，实现了N:M的伪异步I/O模型。

但是，正因为限制了线程数量，如果发生读取数据较慢时（比如数据量大、网络传输慢等），大量并发的情况下，其他接入的消息，只能一直等待，这就是最大的弊端。

原生JDK网络编程NIO

什么是NIO？

NIO 库是在 JDK 1.4 中引入的。NIO 弥补了原来的 BIO 的不足，它在标准 Java 代码中提供了高速的、面向块的 I/O。NIO被称为 no-blocking io 或者 new io都说得通。

NIO和BIO的主要区别

面向流与面向缓冲

Java NIO和BIO之间第一个最大的区别是，BIO是面向流的，NIO是面向缓冲区的。

Java BIO面向流意味着每次从流中读一个或多个字节，直至读取所有字节，它们没有被缓存在任何地方。此外，它不能前后移动流中的数据。如果需要前后移动从流中读取的数据，需要先将它缓存到一个缓冲区。

Java NIO的缓冲导向方法略有不同。数据读取到一个它稍后处理的缓冲区，需要时可在缓冲区中前后移动。这就增加了处理过程中的灵活性。但是，还需要检查是否该缓冲区中包含所有需要处理的数据。而且，需确保当更多的数据读入缓冲区时，不要覆盖缓冲区里尚未处理的数据。

阻塞与非阻塞IO

Java BIO流是阻塞的。这意味着，当一个线程调用read() 或 write()时，该线程被阻塞，直到有一些数据被读取，或数据完全写入。该线程在此期间不能再干任何事情了。

Java NIO的非阻塞模式，使一个线程从某通道发送请求读取数据，但是它仅能得到目前可用的数据，如果目前没有数据可用时，就什么都不会获取。而不是保持线程阻塞，所以直至数据变的可以读取之前，该线程可以继续做其他的事情。

非阻塞写也是如此。一个线程请求写入一些数据到某通道，但不需要等待它完全写入，这个线程同时可以去做别的事情。线程通常将非阻塞IO的空闲时间用于在其它通道上执行IO操作，所以一个单独的线程现在可以管理多个输入和输出通道（channel）。

NIO之Reactor模式

"反应"器名字中"反应"的由来：

"反应"即"倒置"，"控制逆转",具体事件处理程序不调用反应器，而向反应器注册一个事件处理器，表示自己对某些事件感兴趣，有时间来了，具体事件处理程序通过事件处理器对某个指定的事件发生做出反应；这种控制逆转又称为"好莱坞法则"（不要调用我，让我来调用你）

例如，路人甲去做男士SPA，大堂经理负责服务，路人甲现在只对10000技师感兴趣，但是路人甲去的比较早，就告诉大堂经理，等10000技师上班了或者是空闲了，通知我。等路人甲接到大堂经理通知，做出了反应，把10000技师占住了。然后，路人甲想起上一次的那个10000号房间不错，设备舒适，灯光暧昧，又告诉大堂经理，我对10000号房间很感兴趣，房间空出来了就告诉我，我现在先和10000这个小姐聊下人生，10000号房间空出来了，路人甲再次接到大堂经理通知，路人甲再次做出了反应。

路人甲就是具体事件处理程序，大堂经理就是所谓的反应器，"10000技师上班了"和"10000号房间空闲了"就是事件，路人甲只对这两个事件感兴趣，其他，比如10001号技师或者10002号房间空闲了也是事件，但是路人甲不感兴趣。

大堂经理不仅仅服务路人甲这个人，他还可以同时服务路人乙、丙........，每个人所感兴趣的事件是不一样的，大堂经理会根据每个人感兴趣的事件通知对应的每个人。

NIO三大核心组件

NIO有三大核心组件：Selector选择器、Channel管道、buffer缓冲区。

Selector

Selector的英文含义是"选择器"，也可以称为为"轮询代理器"、"事件订阅器"、"channel容器管理机"都行。

Java NIO的选择器允许一个单独的线程来监视多个输入通道，你可以注册多个通道使用一个选择器(Selectors)，然后使用一个单独的线程来操作这个选择器，进而"选择"通道：这些通道里已经有可以处理的输入，或者选择已准备写入的通道。这种选择机制，使得一个单独的线程很容易来管理多个通道。

应用程序将向Selector对象注册需要它关注的Channel，以及具体的某一个Channel会对哪些IO事件感兴趣。Selector中也会维护一个"已经注册的Channel"的容器。

Channels

通道，被建立的一个应用程序和操作系统交互事件、传递内容的渠道（注意是连接到操作系统）。那么既然是和操作系统进行内容的传递，那么说明应用程序可以通过通道读取数据，也可以通过通道向操作系统写数据，而且可以同时进行读写。

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

通道中的数据总是要先读到一个Buffer，或者总是要从一个Buffer中写入。

buffer缓冲区

我们前面说过JDK NIO是面向缓冲的。Buffer就是这个缓冲，用于和NIO通道进行交互。数据是从通道读入缓冲区，从缓冲区写入到通道中的。以写为例，应用程序都是将数据写入缓冲，再通过通道把缓冲的数据发送出去，读也是一样，数据总是先从通道读到缓冲，应用程序再读缓冲的数据。

缓冲区本质上是一块可以写入数据，然后可以从中读取数据的内存（其实就是数组）。这块内存被包装成NIO Buffer对象，并提供了一组方法，用来方便的访问该块内存。

实现代码

1、Selector对象是通过调用静态工厂方法open()来实例化的，如下：

Selector Selector=Selector.open()；

2、要实现Selector管理Channel，需要将channel注册到相应的Selector上，如下：

channel.configureBlocking(false);

SelectionKey key= channel.register(selector,SelectionKey,OP_READ);

register()方法的第二个参数是"interest集合"，表示选择器所关心的通道操作，它实际上是一个表示选择器在检查通道就绪状态时需要关心的操作的比特掩码。比如一个选择器对通道的read和write操作感兴趣，那么选择器在检查该通道时，只会检查通道的read和write操作是否已经处在就绪状态。

如果Selector对通道的多操作类型感兴趣，可以用"位或"操作符来实现：

int interestSet=SelectionKey.OP_READ|SelectionKey.OP_WRITE;

同时一个 Channel 仅仅可以被注册到一个 Selector 一次, 如果将 Channel 注册到 Selector 多次, 那么其实就是相当于更新 SelectionKey 的 interest set。

SelectionKey

什么是SelectionKey

SelectionKey是一个抽象类,表示selectableChannel在Selector中注册的标识.每个Channel向Selector注册时,都将会创建一个SelectionKey。SelectionKey将Channel与Selector建立了关系，并维护了channel事件。

SelectionKey类型和就绪条件

在向Selector对象注册感兴趣的事件时，JAVA NIO共定义了四种：OP_READ、OP_WRITE、OP_CONNECT、OP_ACCEPT（定义在SelectionKey中），分别对应读、写、请求连接、接受连接等网络Socket操作

服务端和客户端分别感兴趣的类型

ServerSocketChannel和SocketChannel可以注册自己感兴趣的操作类型，当对应操作类型的就绪条件满足时OS会通知channel，下表描述各种Channel允许注册的操作类型，Y表示允许注册，N表示不允许注册，其中服务器SocketChannel指由服务器ServerSocketChannel.accept()返回的对象。

服务器启动ServerSocketChannel，关注OP_ACCEPT事件，

客户端启动SocketChannel，连接服务器，关注OP_CONNECT事件

服务器接受连接，启动一个服务器的SocketChannel，这个SocketChannel可以关注OP_READ、OP_WRITE事件，一般连接建立后会直接关注OP_READ事件

客户端这边的客户端SocketChannel发现连接建立后，可以关注OP_READ、OP_WRITE事件，一般是需要客户端需要发送数据了才关注OP_READ事件

连接建立后客户端与服务器端开始相互发送消息（读写），根据实际情况来关注OP_READ、OP_WRITE事件。

直接内存深入辨析

堆外内存的优点和缺点

堆外内存相比于堆内内存有几个优势：

1 减少了垃圾回收的工作，因为垃圾回收会暂停其他的工作（可能使用多线程或者时间片的方式，根本感觉不到）

2 加快了复制的速度。因为堆内在flush到远程时，会先复制到直接内存（非堆内存），然后在发送；而堆外内存相当于省略掉了这个工作。

而福之祸所依，自然也有不好的一面：

1 堆外内存难以控制，如果内存泄漏，那么很难排查

2 堆外内存相对来说，不适合存储很复杂的对象。一般简单的对象或者扁平化的比较适合。

零拷贝

什么是零拷贝?

零拷贝(英语: Zero-copy) 技术是指计算机执行操作时，CPU不需要先将数据从某处内存复制到另一个特定区域。这种技术通常用于通过网络传输文件时节省CPU周期和内存带宽。

➢零拷贝技术可以减少数据拷贝和共享总线操作的次数，消除传输数据在存储器之间不必要的中间拷贝次数，从而有效地提高数据传输效率

➢零拷贝技术减少了用户进程地址空间和内核地址空间之间因为上下文切换而带来的开销

可以看出没有说不需要拷贝，只是说减少冗余[不必要]的拷贝。

下面这些组件、框架中均使用了零拷贝技术：Kafka、Netty、Rocketmq、Nginx、Apache。

Linux的I/O机制与DMA

在早期计算机中，用户进程需要读取磁盘数据，需要CPU中断和CPU参与，因此效率比较低，发起IO请求，每次的IO中断，都带来CPU的上下文切换。因此出现了------DMA。

DMA(Direct Memory Access，直接内存存取) 是所有现代电脑的重要特色，它允许不同速度的硬件装置来沟通，而不需要依赖于CPU 的大量中断负载。

DMA控制器，接管了数据读写请求，减少CPU的负担。这样一来，CPU能高效工作了。现代硬盘基本都支持DMA。

实际因此IO读取，涉及两个过程：

1、DMA等待数据准备好，把磁盘数据读取到操作系统内核缓冲区；

2、用户进程，将内核缓冲区的数据copy到用户空间。

传统数据传送机制

比如：读取文件，再用socket发送出去，实际经过四次copy。

伪码实现如下：

buffer = File.read()

Socket.send(buffer)

1、第一次：将磁盘文件，读取到操作系统内核缓冲区；

2、第二次：将内核缓冲区的数据，copy到应用程序的buffer；

3、第三步：将application应用程序buffer中的数据，copy到socket网络发送缓冲区(属于操作系统内核的缓冲区)；

4、第四次：将socket buffer的数据，copy到网卡，由网卡进行网络传输。

分析上述的过程，虽然引入DMA来接管CPU的中断请求，但四次copy是存在"不必要的拷贝"的。实际上并不需要第二个和第三个数据副本。应用程序除了缓存数据并将其传输回套接字缓冲区之外什么都不做。相反，数据可以直接从读缓冲区传输到套接字缓冲区。

显然，第二次和第三次数据copy 其实在这种场景下没有什么帮助反而带来开销，这也正是零拷贝出现的背景和意义。

同时，read和send都属于系统调用，每次调用都牵涉到两次上下文切换：

总结下，传统的数据传送所消耗的成本：4次拷贝，4次上下文切换。

4次拷贝，其中两次是DMA copy，两次是CPU copy。

Linux支持的(常见)零拷贝

目的：减少IO流程中不必要的拷贝，当然零拷贝需要OS支持，也就是需要kernel暴露api。

mmap内存映射

硬盘上文件的位置和应用程序缓冲区(application buffers)进行映射（建立一种一一对应关系），由于mmap()将文件直接映射到用户空间，所以实际文件读取时根据这个映射关系，直接将文件从硬盘拷贝到用户空间，只进行了一次数据拷贝，不再有文件内容从硬盘拷贝到内核空间的一个缓冲区。

mmap内存映射将会经历：3次拷贝: 1次cpu copy，2次DMA copy；

sendfile

linux 2.1支持的sendfile

当调用sendfile()时，DMA将磁盘数据复制到kernel buffer，然后将内核中的kernel buffer直接拷贝到socket buffer；但是数据并未被真正复制到socket关联的缓冲区内。取而代之的是，只有记录数据位置和长度的描述符被加入到socket缓冲区中。DMA模块将数据直接从内核缓冲区传递给协议引擎，从而消除了遗留的最后一次复制。但是要注意，这个需要DMA硬件设备支持，如果不支持，CPU就必须介入进行拷贝。

一旦数据全都拷贝到socket buffer，sendfile()系统调用将会return、代表数据转化的完成。socket buffer里的数据就能在网络传输了。

sendfile会经历：3（2，如果硬件设备支持）次拷贝，1（0，，如果硬件设备支持）次CPU copy， 2次DMA copy；

以及2次上下文切换

splice

Linux 从2.6.17 支持splice

数据从磁盘读取到OS内核缓冲区后，在内核缓冲区直接可将其转成内核空间其他数据buffer，而不需要拷贝到用户空间。

如下图所示，从磁盘读取到内核buffer后，在内核空间直接与socket buffer建立pipe管道。

和sendfile()不同的是，splice()不需要硬件支持。

注意splice和sendfile的不同，sendfile是DMA硬件设备不支持的情况下将磁盘数据加载到kernel buffer后，需要一次CPU copy，拷贝到socket buffer。而splice是更进一步，连这个CPU copy也不需要了，直接将两个内核空间的buffer进行pipe。

splice会经历 2次拷贝: 0次cpu copy 2次DMA copy；

以及2次上下文切换

总结Linux中零拷贝

最早的零拷贝定义，来源于

Linux 2.4内核新增 sendfile 系统调用，提供了零拷贝。磁盘数据通过 DMA 拷贝到内核态 Buffer 后，直接通过 DMA 拷贝到 NIO Buffer(socket buffer)，无需 CPU 拷贝。这也是零拷贝这一说法的来源。这是真正操作系统意义上的零拷贝(也就是狭义零拷贝)。

随着发展，零拷贝的概念得到了延伸，就是目前的减少不必要的数据拷贝都算作零拷贝的范畴。

Java生态圈中的零拷贝

Linux提供的零拷贝技术 Java并不是全支持，支持2种(内存映射mmap、sendfile)；

NIO提供的内存映射 MappedByteBuffer

NIO中的FileChannel.map()方法其实就是采用了操作系统中的内存映射方式，底层就是调用Linux mmap()实现的。

将内核缓冲区的内存和用户缓冲区的内存做了一个地址映射。这种方式适合读取大文件，同时也能对文件内容进行更改，但是如果其后要通过SocketChannel发送，还是需要CPU进行数据的拷贝。

NIO提供的sendfile

Java NIO 中提供的 FileChannel 拥有 transferTo 和 transferFrom 两个方法，可直接把 FileChannel 中的数据拷贝到另外一个 Channel，或者直接把另外一个 Channel 中的数据拷贝到 FileChannel。该接口常被用于高效的网络 / 文件的数据传输和大文件拷贝。在操作系统支持的情况下，通过该方法传输数据并不需要将源数据从内核态拷贝到用户态，再从用户态拷贝到目标通道的内核态，同时也避免了两次用户态和内核态间的上下文切换，也即使用了"零拷贝"，所以其性能一般高于 Java IO 中提供的方法。

Kafka中的零拷贝

Kafka两个重要过程都使用了零拷贝技术，且都是操作系统层面的狭义零拷贝，一是Producer生产的数据存到broker，二是 Consumer从broker读取数据。

Producer生产的数据持久化到broker，broker里采用mmap文件映射，实现顺序的快速写入；

Customer从broker读取数据，broker里采用sendfile，将磁盘文件读到OS内核缓冲区后，直接转到socket buffer进行网络发送。

Netty的零拷贝实现

TODO