2、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已经开始向长连接演化。

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

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

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

原生JDK网络编程- NIO

什么是NIO？

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

和BIO的主要区别

面向流与面向缓冲

Java NIO和IO之间第一个最大的区别是，IO是面向流的，NIO是面向缓冲区的。 Java IO面向流意味着每次从流中读一个或多个字节，直至读取所有字节，它们没有被缓存在任何地方。此外，它不能前后移动流中的数据。如果需要前后移动从流中读取的数据，需要先将它缓存到一个缓冲区。 Java NIO的缓冲导向方法略有不同。数据读取到一个它稍后处理的缓冲区，需要时可在缓冲区中前后移动。这就增加了处理过程中的灵活性。但是，还需要检查是否该缓冲区中包含所有需要处理的数据。而且，需确保当更多的数据读入缓冲区时，不要覆盖缓冲区里尚未处理的数据。

阻塞与非阻塞IO

Java IO的各种流是阻塞的。这意味着，当一个线程调用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

其实就是socket

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

• 所有被Selector（选择器）注册的通道，只能是继承了SelectableChannel类的子类。

• ServerSocketChannel：负责接收连接，只对有连接事件感兴趣；应用服务器程序的监听通道。只有通过这个通道，应用程序才能向操作系统注册支持“多路复用IO”的端口监听。同时支持UDP协议和TCP协议。

  如：当有连接进来，Selector就通知ServerSocketChannel去接收连接，产生一个Scoket，包装成一个ScoketChannel，去和客户端进行实际网络读写

• ScoketChannel：TCP Socket套接字的监听通道，一个Socket套接字对应了一个客户端IP：端口 到 服务器IP：端口的通信连接。对读和写网络事件感兴趣

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

buffer缓冲区

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

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

后面的附录详细讲到其中的api等相关内容。

重要概念SelectionKey

什么是SelectionKey

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

可以通过cancel方法取消键,取消的键不会立即从selector中移除,而是添加到cancelledKeys中,在下一次select操作时移除它.所以在调用某个key时,需要使用isValid进行校验.

SelectionKey类型和就绪条件

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

关于OP_WRITE的相关代码可以参见包cn.tuling.nio.nio.writeable

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

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事件。

直接内存

Java中存在着堆、垃圾回收等特性，所以在实际的IO中，在JVM内部的存在着这样一种机制：

在IO读写上，如果是使用堆内存，JDK会先创建一个DirectBuffer，再去执行真正的写操作。这是因为，当我们把一个地址通过JNI传递给底层的C库的时候，有一个基本的要求，就是这个地址上的内容不能失效。然而，在GC管理下的对象是会在Java堆中移动的。也就是说，有可能我把一个地址传给底层的write，但是这段内存却因为GC整理内存而失效了。所以必须要把待发送的数据放到一个GC管不着的地方。这就是调用native方法之前，数据—定要在堆外内存的原因。

可见，站在网络通信的角度DirectBuffer并没有节省什么内存拷贝，只是Java网络通信里因为HeapBuffer必须多做一次拷贝，使用DirectBuffer就会少一次内存拷贝。相比没有使用堆内存的Java程序，使用直接内存的Java程序当然更快一点。

从垃圾回收的角度而言，直接内存不受 GC(新生代的 Minor GC) 影响，只有当执行老年代的 Full GC 时候才会顺便回收直接内存，整理内存的压力也比数据放到HeapBuffer要小。

零拷贝

什么是零拷贝?

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

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

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

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

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

Linux支持的(常见)零拷贝

• mmap内存映射

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

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

以及4次上下文切换，调用mmap函数2次，write函数2次。

• 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次上下文切换

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的零拷贝实现

Netty 的零拷贝主要包含三个方面：

在网络通信上，Netty 的接收和发送 ByteBuffer 采用 DIRECT BUFFERS，使用堆外直接内存进行 Socket 读写，不需要进行字节缓冲区的二次拷贝。如果使用传统的堆内存（HEAP BUFFERS）进行 Socket 读写，JVM 会将堆内存 Buffer 拷贝一份到直接内存中，然后才写入 Socket 中。相比于堆外直接内存，消息在发送过程中多了一次缓冲区的内存拷贝。

在缓存操作上，Netty提供了CompositeByteBuf类，它可以将多个ByteBuf合并为一个逻辑上的ByteBuf，避免了各个ByteBuf之间的拷贝。

通过wrap操作，我们可以将byte[]数组、ByteBuf、 ByteBuffer 等包装成一个 Netty ByteBuf对象，进而避免了拷贝操作。

ByteBuf支持slice 操作，因此可以将ByteBuf分解为多个共享同一个存储区域的ByteBuf，避免了内存的拷贝。

在文件传输上，Netty 的通过FileRegion包装的FileChannel.tranferTo实现文件传输，它可以直接将文件缓冲区的数据发送到目标 Channel，避免了传统通过循环 write 方式导致的内存拷贝问题。