进一步理解网络编程（二）
目前常用的IO通信模型包括四种（这里说的都是网络IO）：阻塞式同步IO、非阻塞式同步IO、多路复用IO、和真正的异步IO。这些IO模式都是要靠操作系统进行支持，应用程序只是提供相应的实现，对操作系统进行调用。
一 IO模型
1.1 阻塞IO
BIO就是：blocking IO。最容易理解、最容易实现的IO工作方式，应用程序向操作系统请求网络IO操作，这时应用程序会一直等待；另一方面，操作系统收到请求后，也会等待，直到网络上有数据传到监听端口；操作系统在收集数据后，会把数据发送给应用程序；最后应用程序受到数据，并解除等待状态。
JAVA对阻塞模式的支持，就是java.net包中的Socket套接字实现。这里要说明一下，Socket套接字是TCP/UDP等传输层协议的实现。例如客户端使用TCP协议连接这台服务器的时候，当TCP三次握手成功后，应用程序就会创建一个socket套接字对象（注意，这是还没有进行数据内容的传输），当这个TCP连接出现数据传输时，socket套接字就会把数据传输的表现告诉程序员（例如read方法接触阻塞状态）。
package com.shu.IO;
import com.shu.thread.SocketServer1;
import org.apache.log4j.Logger;
import java.io.InputStream;
import java.io.OutputStream;
import java.net.ServerSocket;
import java.net.Socket;
/**
* @description: 阻塞IO模型
* @author: shu
* @createDate: 2023/12/27 18:43
* @version: 1.0
*/
public class SocketServer01 {
private static final Logger LOGGER = Logger.getLogger(SocketServer01.class);
public static void main(String[] args) {
ServerSocket serverSocket = null;
try {
serverSocket = new ServerSocket(83);
LOGGER.info("服务器启动成功");
while (true) {
// 通过调用accept方法监听客户端请求，该方法会阻塞，直到接收到客户端的请求
Socket socket = serverSocket.accept();
// 有客户端请求时，会执行下面的代码
//下面我们收取信息
InputStream in = socket.getInputStream();
OutputStream out = socket.getOutputStream();
Integer sourcePort = socket.getPort();
int maxLen = 2048;
byte[] contextBytes = new byte[maxLen];
//这里也会被阻塞，直到有数据准备好
int realLen = in.read(contextBytes, 0, maxLen);
//读取信息
String message = new String(contextBytes, 0, realLen);
//下面打印信息
LOGGER.info("服务器收到来自于端口：" + sourcePort + "的信息：" + message);
//下面开始发送信息
out.write("回发响应信息！".getBytes());
//关闭
out.close();
in.close();
socket.close();
}
} catch (Exception e) {
LOGGER.error(e.getMessage(), e);
} finally {
if (serverSocket != null) {
try {
serverSocket.close();
} catch (Exception e) {
LOGGER.error(e.getMessage(), e);
}
}
}
}
}
- 代码执行到serverSocket.accept()的位置就会等待，这个调用的含义是应用程序向操作系统请求客户端连接的接收，这是代码会阻塞，而底层调用的位置在DualStackPlainSocketImpl这个类里面（注意我使用的测试环境是windows 8 ，所以是由这个类处理
DualStackPlainSocketImpl
void socketAccept(SocketImpl s) throws IOException {
int nativefd = checkAndReturnNativeFD();
if (s == null)
throw new NullPointerException("socket is null");
int newfd = -1;
InetSocketAddress[] isaa = new InetSocketAddress[1];
if (timeout <= 0) {
newfd = accept0(nativefd, isaa);
} else {
configureBlocking(nativefd, false);
try {
waitForNewConnection(nativefd, timeout);
newfd = accept0(nativefd, isaa);
if (newfd != -1) {
configureBlocking(newfd, true);
}
} finally {
configureBlocking(nativefd, true);
}
}
/* Update (SocketImpl)s' fd */
fdAccess.set(s.fd, newfd);
/* Update socketImpls remote port, address and localport */
InetSocketAddress isa = isaa[0];
s.port = isa.getPort();
s.address = isa.getAddress();
s.localport = localport;
}
DualStackPlainSocketImpl
static native int accept0(int fd, InetSocketAddress[] isaa) throws IOException;
我这里是Windows，他就是调用操作系统的方法：accept
SOCKET WSAAPI accept(
[in] SOCKET s,
[out] sockaddr *addr,
[in, out] int *addrlen
);
- 如果您是在windows 7环境下进行测试，那么处理类是TwoStacksPlainSocketImpl，这是Windows环境；如果您使用的测试环境是Linux，那么视Linux的内核版本而异，具体的处理类又是不一样的
- linux参考：https://blog.csdn.net/mrpre/article/details/82655834
1.2 非阻塞IO
一定要注意：阻塞/非阻塞的描述是针对应用程序中的线程进行的，对于阻塞方式的一种改进是应用程序将其“一直等待”的状态主动打开，如下图所示：
这种模式下，应用程序的线程不再一直等待操作系统的IO状态，而是在等待一段时间后，就解除阻塞。如果没有得到想要的结果，则再次进行相同的操作，这样的工作方式，暴增了应用程序的线程可以不会一直阻塞，而是可以进行一些其他工作。
package com.shu.IO;
import org.apache.log4j.Logger;
import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;
import java.net.ServerSocket;
import java.net.Socket;
import java.net.SocketTimeoutException;
/**
* @description: 非阻塞IO模型
* @author: shu
* @createDate: 2023/12/27 19:03
* @version: 1.0
*/
public class SocketServer02 {
private static final Logger LOGGER = Logger.getLogger(SocketServer02.class);
private static Object xWait = new Object();
public static void main(String[] args) throws IOException {
ServerSocket serverSocket = null;
try {
serverSocket = new ServerSocket(83);
serverSocket.setSoTimeout(100);
while(true) {
Socket socket = null;
try {
socket = serverSocket.accept();
} catch(SocketTimeoutException e1) {
//===========================================================
// 执行到这里，说明本次accept没有接收到任何数据报文
// 主线程在这里就可以做一些事情，记为X
//===========================================================
synchronized (SocketServer02.xWait) {
LOGGER.info("这次没有从底层接收到任务数据报文，等待10毫秒，模拟事件X的处理时间");
SocketServer02.xWait.wait(10);
}
continue;
}
InputStream in = socket.getInputStream();
OutputStream out = socket.getOutputStream();
Integer sourcePort = socket.getPort();
int maxLen = 2048;
byte[] contextBytes = new byte[maxLen];
int realLen;
StringBuffer message = new StringBuffer();
//下面我们收取信息（这里还是阻塞式的,一直等待，直到有数据可以接受）
while((realLen = in.read(contextBytes, 0, maxLen)) != -1) {
message.append(new String(contextBytes , 0 , realLen));
/*
* 我们假设读取到“over”关键字，
* 表示客户端的所有信息在经过若干次传送后，完成
* */
if(message.indexOf("over") != -1) {
break;
}
}
//下面打印信息
LOGGER.info("服务器收到来自于端口：" + sourcePort + "的信息：" + message);
//下面开始发送信息
out.write("回发响应信息！".getBytes());
//关闭
out.close();
in.close();
socket.close();
}
} catch(Exception e) {
LOGGER.error(e.getMessage(), e);
} finally {
if(serverSocket != null) {
serverSocket.close();
}
}
}
}
那么timeout是在哪里设置的呢？在ServerSocket中，调用了DualStackPlainSocketImpl的父类SocketImpl进行timeout的设置
这里我们针对了SocketServer增加了阻塞等待时间，实际上只实现了非阻塞IO模型中的第一步：监听连接状态的非阻塞。通过运行代码，我们可以发现read()方法还是被阻塞的，说明socket套接字等待数据读取的过程，还是阻塞方式。
1.3 多路复用IO
我们试想一下这样的现实场景：
- 一个餐厅同时有100位客人到店，当然到店后第一件要做的事情就是点菜。但是问题来了，餐厅老板为了节约人力成本目前只有一位大堂服务员拿着唯一的一本菜单等待客人进行服务。
- 那么最笨（但是最简单）的方法是（方法A），无论有多少客人等待点餐，服务员都把仅有的一份菜单递给其中一位客人，然后站在客人身旁等待这个客人完成点菜过程。在记录客人点菜内容后，把点菜记录交给后堂厨师。然后是第二位客人。。。。然后是第三位客人。很明显，只有脑袋被门夹过的老板，才会这样设置服务流程。因为随后的80位客人，再等待超时后就会离店（还会给差评）。
- 于是还有一种办法（方法B），老板马上新雇佣99名服务员，同时印制99本新的菜单。每一名服务员手持一本菜单负责一位客人（关键不只在于服务员，还在于菜单。因为没有菜单客人也无法点菜）。在客人点完菜后，记录点菜内容交给后堂厨师（当然为了更高效，后堂厨师最好也有100名）。这样每一位客人享受的就是VIP服务咯，当然客人不会走，但是人力成本可是一个大头哦（亏死你）。
- 另外一种办法（方法C），就是改进点菜的方式，当客人到店后，自己申请一本菜单。想好自己要点的才后，就呼叫服务员。服务员站在自己身边后记录客人的菜单内容。将菜单递给厨师的过程也要进行改进，并不是每一份菜单记录好以后，都要交给后堂厨师。服务员可以记录号多份菜单后，同时交给厨师就行了。那么这种方式，对于老板来说人力成本是最低的；对于客人来说，虽然不再享受VIP服务并且要进行一定的等待，但是这些都是可接受的；对于服务员来说，基本上她的时间都没有浪费，基本上被老板压杆了最后一滴油水。
如果您是老板，您会采用哪种方式呢？
- 到店情况：并发量。到店情况不理想时，一个服务员一本菜单，当然是足够了。所以不同的老板在不同的场合下，将会灵活选择服务员和菜单的配置。
- 客人：客户端请求
- 点餐内容：客户端发送的实际数据
- 老板：操作系统
- 人力成本：系统资源
- 菜单：文件状态描述符。操作系统对于一个进程能够同时持有的文件状态描述符的个数是有限制的，在linux系统中$ulimit -n查看这个限制值，当然也是可以（并且应该）进行内核参数调整的。
- 服务员：操作系统内核用于IO操作的线程（内核线程）
- 厨师：应用程序线程（当然厨房就是应用程序进程咯）
- 餐单传递方式：包括了阻塞式和非阻塞式两种。
- 方法A：阻塞式/非阻塞式 同步IO
- 方法B：使用线程进行处理的 阻塞式/非阻塞式 同步IO
- 方法C：阻塞式/非阻塞式 多路复用IO
目前流程的多路复用IO实现主要包括四种：select、poll、epoll、kqueue。下表是他们的一些重要特性的比较：
多路复用IO技术最适用的是“高并发”场景，所谓高并发是指1毫秒内至少同时有上千个连接请求准备好。其他情况下多路复用IO技术发挥不出来它的优势。另一方面，使用JAVA NIO进行功能实现，相对于传统的Socket套接字实现要复杂一些，所以实际应用中，需要根据自己的业务需求进行技术选择。
具体参考NIO 详解
NIO 基本架构
优缺点
- 不用再使用多线程来进行IO处理了（包括操作系统内核IO管理模块和应用程序进程而言）。当然实际业务的处理中，应用程序进程还是可以引入线程池技术的
- 同一个端口可以处理多种协议，例如，使用ServerSocketChannel测测的服务器端口监听，既可以处理TCP协议又可以处理UDP协议。
- 操作系统级别的优化：多路复用IO技术可以是操作系统级别在一个端口上能够同时接受多个客户端的IO事件。同时具有之前我们讲到的阻塞式同步IO和非阻塞式同步IO的所有特点。Selector的一部分作用更相当于“轮询代理器”。
- 都是同步IO：目前我们介绍的 阻塞式IO、非阻塞式IO甚至包括多路复用IO，这些都是基于操作系统级别对“同步IO”的实现。我们一直在说“同步IO”，一直都没有详细说，什么叫做“同步IO”。实际上一句话就可以说清楚：只有上层（包括上层的某种代理机制）系统询问我是否有某个事件发生了，否则我不会主动告诉上层系统事件发生了
1.4 异步IO
- 阻塞式同步IO、非阻塞式同步IO、多路复用IO 这三种IO模型，以及JAVA对于这三种IO模型的支持。重点说明了IO模型是由操作系统提供支持，且这三种IO模型都是同步IO，都是采用的“应用程序不询问我，我绝不会主动通知”的方式。
- 异步IO则是采用“订阅-通知”模式：即应用程序向操作系统注册IO监听，然后继续做自己的事情。当操作系统发生IO事件，并且准备好数据后，在主动通知应用程序，触发相应的函数：
- 和同步IO一样，异步IO也是由操作系统进行支持的。微软的windows系统提供了一种异步IO技术：IOCP（I/O Completion Port，I/O完成端口）；
- Linux下由于没有这种异步IO技术，所以使用的是epoll（上文介绍过的一种多路复用IO技术的实现）对异步IO进行模拟。
AIO框架
具体参考：https://yinwj.blog.csdn.net/article/details/48784375