从实践角度重新理解BIO和NIO
https://mp.weixin.qq.com/s/rsvAmmoJiseEmjChI95m6Q
1 bio的2次阻塞与缺陷
服务器端在启动后，首先需要等待客户端的连接请求（第一次阻塞），如果没有客户端连接，服务端将一直阻塞等待，然后当客户端连接后，服务器会等待客户端发送数据（第二次阻塞），如果客户端没有发送数据，那么服务端将会一直阻塞等待客户端发送数据。
BIO会产生两次阻塞，第一次在等待连接时阻塞，第二次在等待数据时阻塞。
当我们的服务器接收到一个连接后，并且没有接收到客户端发送的数据时，是会阻塞在read()方法中的，那么此时如果再来一个客户端的请求，服务端是无法进行响应的。在不考虑多线程的情况下，BIO是无法处理多个客户端请求的。
2 多线程的bio
我们只需要在每一个连接请求到来时，创建一个线程去执行这个连接请求，就可以在BIO中处理多个客户端请求了，这也就是为什么BIO的其中一条概念是服务器实现模式为一个连接一个线程，即客户端有连接请求时服务器端就需要启动一个线程进行处理。
while (true) {
System.out.println();
System.out.println("服务器正在等待连接...");
Socket socket = serverSocket.accept(); 【重点阻塞】
new Thread(new Runnable() {
@Override
public void run() {
System.out.println("服务器已接收到连接请求...");
System.out.println();
System.out.println("服务器正在等待数据...");
try {
socket.getInputStream().read(buffer); 【重点阻塞】
} catch (IOException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
System.out.println("服务器已经接收到数据");
System.out.println();
String content = new String(buffer);
System.out.println("接收到的数据:" + content);
}
}).start();
}
3 多线程bio弊端
1）线程切换
2）线程资源浪费在不说话的连接上
4 模拟nio，同步非阻塞模型
其实NIO需要解决的最根本的问题就是存在于BIO中的两个阻塞，分别是等待连接时的阻塞和等待数据时的阻塞。
如果单线程服务器在等待数据时阻塞，那么第二个连接请求到来时，服务器是无法响应的。如果是多线程服务器，那么又会有为大量空闲请求产生新线程从而造成线程占用系统资源，线程浪费的情况。
单线程服务器接收数据时阻塞，而无法接收新请求的问题，那么其实可以让服务器在等待数据时不进入阻塞状态，问题不就迎刃而解了吗？
4.1
//设置为非阻塞
serverSocketChannel.configureBlocking(false);【重点非阻塞】
while(true) {
SocketChannel socketChannel = serverSocketChannel.accept();
if(socketChannel==null) {
//表示没人连接
System.out.println("正在等待客户端请求连接...");
Thread.sleep(5000);
}else {
System.out.println("当前接收到客户端请求连接...");
}
if(socketChannel!=null) {
//设置为非阻塞
socketChannel.configureBlocking(false); 【重点非阻塞】
byteBuffer.flip();//切换模式 写-->读
int effective = socketChannel.read(byteBuffer);
if(effective!=0) {
String content = Charset.forName("utf-8").decode(byteBuffer).toString();
System.out.println(content);
}else {
System.out.println("当前未收到客户端消息");
}
}
在这种解决方案下，虽然在接收客户端消息时不会阻塞，但是又开始重新接收服务器请求，用户根本来不及输入消息，服务器就转向接收别的客户端请求了
4.2
我们将连接存储在一个list集合中，每次等待客户端消息时都去轮询，看看消息是否准备好，如果准备好则直接打印消息。
//设置为非阻塞
serverSocketChannel.configureBlocking(false);
while(true) {
SocketChannel socketChannel = serverSocketChannel.accept();
if(socketChannel==null) {
//表示没人连接
System.out.println("正在等待客户端请求连接...");
Thread.sleep(5000);
}else {
System.out.println("当前接收到客户端请求连接...");
socketList.add(socketChannel); 【重点缓存】
}
for(SocketChannel socket:socketList) { 【重点遍历缓存】
socket.configureBlocking(false);
int effective = socket.read(byteBuffer);
if(effective!=0) {
byteBuffer.flip();//切换模式 写-->读
String content = Charset.forName("UTF-8").decode(byteBuffer).toString();
System.out.println("接收到消息:"+content);
byteBuffer.clear();
}else {
System.out.println("当前未收到客户端消息");
}
}
我们采用了一个轮询的方式来接收消息，每次都轮询所有的连接，看消息是否准备好，测试用例中只是三个连接，所以看不出什么问题来，但是我们假设有1000万连接，甚至更多，采用这种轮询的方式效率是极低的。
另外，1000万连接中，我们可能只会有100万会有消息，剩下的900万并不会发送任何消息，那么这些连接程序依旧要每次都去轮询，这显然是不合适的。
5 真实nio
在真实NIO中，并不会在Java层上来进行一个轮询，而是将轮询的这个步骤交给我们的操作系统来进行，他将轮询的那部分代码改为操作系统级别的系统调用（select函数，在linux环境中为epoll），在操作系统级别上调用select函数，主动地去感知有数据的socket。
我们写的Java程序其本质在轮询每个Socket的时候也需要去调用系统函数，那么轮询一次调用一次，会造成不必要的上下文切换开销。用户态-内核态切换
5.1 windows select
如果select没有查询到到有数据的请求，那么将会一直阻塞（是的，select是一个阻塞函数）。如果有一个或者多个请求已经准备好数据了，那么select将会先将有数据的文件描述符置位，然后select返回。返回后通过遍历查看哪个请求有数据。
-
底层存储依赖bitmap，处理的请求是有上限的，为1024。
- fd 用户-内核拷贝
- 再次遍历
5.2 linux poll
poll内部存储不依赖bitmap，而是使用pollfd数组的这样一个数据结构，数组的大小肯定是大于1024的。但仍有后2个缺点
5.3 epoll
epoll和上述两个函数最大的不同是，它的fd是共享在用户态和内核态之间的，所以可以不必进行从用户态到内核态的一个拷贝，这样可以节约系统资源；另外，在select和poll中，如果某个请求的数据已经准备好，它们会将所有的请求都返回，供程序去遍历查看哪个请求存在数据，但是epoll只会返回存在数据的请求，这是因为epoll在发现某个请求存在数据时，首先会进行一个重排操作，将所有有数据的fd放到最前面的位置，然后返回（返回值为存在数据请求的个数N），那么我们的上层程序就可以不必将所有请求都轮询，而是直接遍历epoll返回的前N个请求，这些请求都是有数据的请求。
6
-
Java NIO (non-blocking I/O)： 同步非阻塞，服务器实现模式为一个请求一个线程，即客户端发送的连接请求都会注册到多路复用器上，多路复用器轮询到连接有I/O请求时才启动一个线程进行处理。
阻塞io个人认为可再分为单线程和多线程，缺点：
single：连接1的read会阻塞连接2的connect
multi：线程切换、僵尸连接
本质上io都是阻塞的，multi版本业务上非阻塞
io复用之非阻塞体现在用户态select/epoll阻塞，内核态非阻塞轮训各channel，which在连接创建时被注册到selector上
另一片比较重要的文章：5种io模型摘要