一、为什么必须去理解NIO
首先你须要之后Netty的次要实现伎俩就是Nio,很多人始终学不明确Netty，根本原因是 除了日常开发中很难可能实际，很大一部分起因是不相熟NIO，事实上真正相熟了NIO和它背地的原理之后，去查看Netty的源码就有如神助！咱们明天就从最根本的IO、以及NIO学起！欢送关注公众号【源码学徒】
二、操作系统是如何定义I/O的
I/O相干的操作，具体各位从事java的人员并不生疏，顾名思义也就是Input/Output,对应着连个动词，Read/Write 读写两个动作，然而在下层零碎利用中无论是读还是写，操作系统都不会间接的操作物理机磁盘数据，而是由零碎内核加载磁盘数据！咱们以Read为例，当程序中发动了一个Read申请后，操作系统会将数据从内核缓冲区加载到用户缓冲区，如果内核缓冲区内没有数据，内核会将该次读申请追加到申请队列，当内核将磁盘数据读取到内核缓冲区后，再次执行读申请，将内核缓冲区的数据复制到用户缓冲区，继而返回给下层利用零碎！
write申请也是相似于上图的状况，用户过程写入到用户缓冲区，复制到内核缓冲区，而后当数据达到一定量级之后由内核写入到网口或者磁盘文件！
假如咱们以Socket服务端为例，咱们口述一下一个残缺的读写操作的流程：
- 客户端发送一个数据到网卡，由操作系统内核将数据复制到内核缓冲区！
- 当用户过程发动read申请后，将数据从内核缓冲区复制到用户缓冲区！
- 用户缓冲区获取到数据之后程序开始进行业务解决！解决实现后，调用Write申请，将数据从用户缓冲区写入到内核缓冲区！
- 零碎内核将数据从内核缓冲区写入到网卡，通过底层的通信协定发送到客户端！
三、网络编程中的IO模型
本文旨在让初学者先大抵理解一下基本原理，所以这里并不会波及到太多代码，具体的实现逻辑，能够关注后续源码剖析的时候的文章，这里只做一个铺垫，为日后的学习做一个比拟好的铺垫！
1. 同步阻塞I/O
I. 传统的阻塞IO模型
这种模型是单线程利用，服务端监听客户端连贯，当监听到客户端的连贯后立刻去做业务逻辑的解决，该次申请没有解决实现之前，服务端接管到的其余连贯全副阻塞不可操作！当然开发中，咱们也不会这样写，这种写法只会存在于协定demo中！这种写法的缺点在哪呢？
咱们看图发现，当一个新连贯被接入后，其余客户端的连贯全副处于阻塞状态，那么当该客户端解决客户端工夫过长的时候，会导致阻塞的客户端连贯越来越多导致系统解体，咱们是否可能找到一个方法，使其可能将业务解决与Accept接管新连贯拆散开来！这样业务解决不影响新连贯接入就可能解决该问题！
II. 伪异步阻塞IO模型
这种业务模型是是对上一步单线程模型的一种优化，当一个新连贯接入后，获取到这个链接的Socket,交给一条新的线程去解决，主程序持续接管下一个新连贯，这样就可能解决同一时间只能解决一个新连贯的问题，然而，明眼人都能看进去，这样有一个很致命的问题，这种模型解决小并发短时间可能不会呈现问题，然而假如有10w连贯接入，我须要开启10w个线程，这样会把零碎间接压崩！咱们须要限度线程的数量，那么必定就会想到线程池，咱们来优化一下这个模型吧！
III. 优化伪异步阻塞IO模型
这个模型是JDK1.4之前，没有NIO的时候的一个经典Socket模型，服务端接管到客户端新连贯会后，将Socket连贯以及业务逻辑包装为工作提交到线程池，由线程池开始执行，同时服务端持续接管新连贯！这样可能解决上一步因为线程爆炸所引发的问题，然而咱们回忆下线程池的的提交步骤：当外围线程池满了之后会将工作搁置到队列，当队列满了之后，会占用最大线程数的数量持续开启线程，当达到最大线程数的时候开始回绝策略！ 证实我最大的并发数只有1500个，其余的都在队列外面占1024个，假如当初的连接数是1w个，并且应用的是抛弃策略，那么会有近6000的连贯工作被抛弃掉，而且1500个线程，线程之间的切换也是一个特地大的开销！这是一个致命的问题！
上述的三种模型除了有上述的问题之外，还有一个特地致命的问题，他是阻塞的！
在哪里阻塞的呢？
- 连贯的时候，当没有客户端连贯的时候是阻塞的！没有客户端连贯的时候，线程只能傻傻的阻塞在哪里期待新连贯接入！
- 期待数据写入的时候是阻塞的，当一个新连贯接入后然而不写入数据，那么线程会始终期待数据写入，直到数据写入实现后才会进行阻塞！ 假如咱们应用 优化后的伪异步线程模型 ，1000个连贯可能只有 100个连贯会频繁写入数据，残余900个连贯都很少写入，那么就会有900个线程在傻傻期待客户端写入数据，所以，这也是一个很重大的性能开销！
当初咱们总结一下上述模型的问题：
- 线程开销节约重大！
- 线程间的切换频繁，效率低下！
- read/write执行的时候会进行阻塞！
- accept会阻塞期待新连贯
那么，咱们是否有一种计划，用很少的线程去治理成千上万的连贯，read/write会阻塞过程，那么就会进入到上面的模型
2. 同步非阻塞I/O
同步非阻塞I/O模型就必须应用java NIO来实现了，看一段简略的代码：
public static void main(String[] args) throws IOException { //新接连池 List<SocketChannel> socketChannelList = new ArrayList<>(8); //开启服务端Socket ServerSocketChannel serverSocketChannel = ServerSocketChannel.open(); serverSocketChannel.bind(new InetSocketAddress(8098)); //设置为非阻塞 serverSocketChannel.configureBlocking(false); while (true) { //探测新连贯，因为设置了非阻塞，这里即便没有新连贯也不会阻塞，而是间接返回null SocketChannel socketChannel = serverSocketChannel.accept(); //当返回值不为null的时候，证实存在新连贯 if(socketChannel!=null){ System.out.println("新连贯接入"); //将客户端设置为非阻塞 这样read/write不会阻塞 socketChannel.configureBlocking(false); //将新连贯退出到线程池 socketChannelList.add(socketChannel); } //迭代器遍历连接池 Iterator<SocketChannel> iterator = socketChannelList.iterator(); while (iterator.hasNext()) { ByteBuffer byteBuffer = ByteBuffer.allocate(128); SocketChannel channel = iterator.next(); //读取客户端数据 当客户端数据没有写入实现的时候也不会阻塞，长度为0 int read = channel.read(byteBuffer); if(read > 0) { //当存在数据的时候打印数据 System.out.println(new String(byteBuffer.array())); }else if(read == -1) { //客户端退出的时候删除该连贯 iterator.remove(); System.out.println("断开连接"); } } }}上述代码咱们能够看到一个要害的逻辑：serverSocketChannel.configureBlocking(false); 这里被设置为非阻塞的时候无论是 accept还是read/write都不会阻塞！具体的为什么会非阻塞，我放到文章前面说，咱们看一下这种的实现逻辑有什么问题！
看这里，咱们仿佛确实应用了一条线程解决了所有的连贯以及读写操作，然而假如咱们有10w连贯，沉闷连贯（常常read/write）只有1000，然而咱们这个线程须要每次否轮询10w条数据处理，极大的耗费了CPU！
咱们期待什么？ 期待的是，每次轮询值轮询有数据的Channel, 没有数据的就不论他，比方刚刚的例子，只有1000个沉闷连贯，那么每次就只轮询这1000个，其余的有读写了有数据就轮询，没读写就不轮询！
3. 多路复用模型
多路复用模型是JAVA NIO 举荐应用的经典模型，外部通过 Selector进行事件抉择，Selector事件抉择通过零碎实现，具体流程看一段代码:
public static void main(String[] args) throws IOException { //开启服务端Socket ServerSocketChannel serverSocketChannel = ServerSocketChannel.open(); serverSocketChannel.bind(new InetSocketAddress(8098)); //设置为非阻塞 serverSocketChannel.configureBlocking(false); //开启一个选择器 Selector selector = Selector.open(); serverSocketChannel.register(selector, SelectionKey.OP_ACCEPT); while (true) { // 阻塞期待须要解决的事件产生 selector.select(); // 获取selector中注册的全副事件的 SelectionKey 实例 Set<SelectionKey> selectionKeys = selector.selectedKeys(); //获取曾经筹备实现的key Iterator<SelectionKey> iterator = selectionKeys.iterator(); while (iterator.hasNext()) { SelectionKey next = iterator.next(); //当发现连贯事件 if(next.isAcceptable()) { //获取客户端连贯 SocketChannel socketChannel = serverSocketChannel.accept(); //设置非阻塞 socketChannel.configureBlocking(false); //将该客户端连贯注册进选择器 并关注读事件 socketChannel.register(selector, SelectionKey.OP_READ); //如果是读事件 }else if(next.isReadable()){ ByteBuffer allocate = ByteBuffer.allocate(128); //获取与此key惟一绑定的channel SocketChannel channel = (SocketChannel) next.channel(); //开始读取数据 int read = channel.read(allocate); if(read > 0){ System.out.println(new String(allocate.array())); }else if(read == -1){ System.out.println("断开连接"); channel.close(); } } //删除这个事件 iterator.remove(); } }}相比下面的同步非阻塞IO，这里多了一个selector选择器，可能对关注不同事件的Socket进行注册，后续如果关注的事件满足了条件的话，就将该socket放回到到外面，期待客户端轮询！
NIO底层在JDK1.4版本是用linux的内核函数select()或poll()来实现，跟下面的NioServer代码相似，selector每次都会轮询所有的sockchannel看下哪个channel有读写事件，有的话就解决，没有就持续遍历，JDK1.5开始引入了epoll基于事件响应机制来优化NIO，首先咱们会将咱们的SocketChannel注册到对应的选择器上并抉择关注的事件，后续操作系统会依据咱们设置的感兴趣的事件将实现的事件SocketChannel放回到选择器中，期待用户的解决！那么它可能解决上述的问题吗？
必定是能够的，因为下面的一个同步非阻塞I/O痛点在于CPU总是在做很多无用的轮询，在这个模型里被解决了！这个模型从selector中获取到的Channel全副是就绪的，后续只须要也就是说他每次轮询都不会做无用功！
深刻 底层概念解析
select模型
如果要深入分析NIO的底层咱们须要逐渐的剖析，首先，咱们须要理解一种叫做select()函数的模型，它是什么呢？他也是NIO所应用的多路复用的模型之一，是JDK1.4的时候所应用的一种模型，他是epoll模型之前所广泛应用的一种模型，他的效率不高，然而过后被广泛应用，起初才会被人优化为epoll！
他是如何做到多路复用的呢？如图：
- 首先咱们须要理解操作系统有一个叫做工作队列的概念，由CPU轮流执行工作队列外面的过程，咱们平时书写的Socket服务端客户端程序也是存在于工作队列的过程中，只有它存在于工作队列，它就会被CPU调用执行！咱们下文将该网络程序称之为过程A
- 他的外部会保护一个 Socket列表，当调用零碎函数select(socket[])的时候，操作系统会将过程A退出到Socket列表中的每一个Socket的期待队列中，同时将过程A从工作队列移除，此时，过程A处于阻塞状态！
当网卡接管到数据之后，触发操作系统的中断程序，依据该程序的Socket端口取对应的Socket列表中寻找该过程A，并将过程A从所有的Socket列表中的期待队列移除，并退出到操作系统的工作队列！
此时过程A被唤醒，此时晓得至多有一个Socket存在数据，开始顺次遍历所有的Socket，寻找存在数据的Socket并进行后续的业务操作
该种构造的核心思想是，我先让所有的Socket都持有这个过程A的援用，当操作系统触发Socket中断之后，基于端口寻找到对应的Socket,就可能找到该Socket对应的过程，再基于过程，就可能找到所有被监控的Socket! 要留神，当过程A被唤醒，就证实一件事，操作系统产生了Socket中断，就至多有一个Socket的数据准备就绪，只须要将所有的Socket遍历，就可能找到并解决本次客户端传入的数据！
然而，你会发现，这种操作极为繁琐，两头仿佛存在了很多遍历，先将过程A退出的所有的Socket期待队列须要遍历一次，产生中断之后须要遍历一次Socket列表，将所有对于过程A的援用移除，并将过程A的援用退出到工作队列！因为此时过程A并不知道哪一个Socket是有数据的，所以，由须要再次遍历一遍Socket列表，能力真正的解决数据，整个操作总共遍历了3此Socket，为了保障性能，所以1.4版本种，最多只能监控1024个Socket,去掉规范输入输入和谬误输入只剩下1021个，因为如果Socket过多势必造成每次遍历耗费性能极大！
epoll模型
epoll总共分为三个比拟重要的函数：
- epoll_create 对应JDK NIO代码种的Selector.open()
- epoll_ctl 对应JDK NIO代码中的socketChannel.register(selector,xxxx);
- epoll_wait 对应JDK NIO代码中的 selector.select();
感兴趣的能够下载一个open-jdk-8u的源代码，也能够关注公众号回复openJdk获取源码压缩包！
他是如何优化select的呢？
epoll_create：这些零碎调用将返回一个非负文件描述符，他也和Socket一样，存在一个期待队列，然而，他还存在一个就绪队列！
epoll_ctl ：增加Socket的监督，对应Java中将SocketChannel注册到Selector中，他会将创立的文件描述符的援用增加到Socket的期待队列！这点比拟难了解，留神是将EPFD（Epoll文件描述符）放到Socket的期待队列！
当操作系统产生中断程序后，基于端口号（客户端的端口号是惟一的）寻找到对应的Socket,获取到EPFD的援用，将该Socket的援用退出到EPFD的就序列表！
epoll_wait：查看EPFD的就绪列表是否存在Socket的援用，如果存在就间接返回，不存在就将过程A退出到EPFD的期待队列，并移除过程A再工作队列的援用！
当网卡再次接管到数据，产生中断，进行上述步骤，将该Socket的因援用退出到就序列表，并唤醒过程A，移除该EPFD期待队列的过程A，将过程A退出到工作队列，程序继续执行！
4. 异步非阻塞I/O
异步非阻塞模型是用户利用只须要收回对应的事件，并注册对应的回调函数，由操作系统实现后，回调回调函数，实现具体的约为操作！先看一段代码
public static void main(String[] args) throws Exception { final AsynchronousServerSocketChannel serverChannel = AsynchronousServerSocketChannel.open().bind(new InetSocketAddress(9000)); //监听连贯事件，并注册回调 serverChannel.accept(null, new CompletionHandler<AsynchronousSocketChannel, Object>() { @Override public void completed(AsynchronousSocketChannel socketChannel, Object attachment) { try { System.out.println("2--"+Thread.currentThread().getName()); // 再此接管客户端连贯，如果不写这行代码前面的客户端连贯连不上服务端 serverChannel.accept(attachment, this); System.out.println(socketChannel.getRemoteAddress()); ByteBuffer buffer = ByteBuffer.allocate(1024); //监听read事件并注册回调 socketChannel.read(buffer, buffer, new CompletionHandler<Integer, ByteBuffer>() { @Override public void completed(Integer result, ByteBuffer buffer) { System.out.println("3--"+Thread.currentThread().getName()); buffer.flip(); System.out.println(new String(buffer.array(), 0, result)); //向客户端回写一个数据 socketChannel.write(ByteBuffer.wrap("HelloClient".getBytes())); } //产生谬误调这个 @Override public void failed(Throwable exc, ByteBuffer buffer) { exc.printStackTrace(); } }); } catch (IOException e) { e.printStackTrace(); } } //产生谬误调这个 @Override public void failed(Throwable exc, Object attachment) { exc.printStackTrace(); } }); System.out.println("1--"+Thread.currentThread().getName()); Thread.sleep(Integer.MAX_VALUE); }}AIO客户端
public static void main(String... args) throws Exception { AsynchronousSocketChannel socketChannel = AsynchronousSocketChannel.open(); socketChannel.connect(new InetSocketAddress("127.0.0.1", 9000)).get(); socketChannel.write(ByteBuffer.wrap("HelloServer".getBytes())); ByteBuffer buffer = ByteBuffer.allocate(512); Integer len = socketChannel.read(buffer).get(); if (len != -1) { System.out.println("客户端收到信息：" + new String(buffer.array(), 0, len)); }}整体逻辑就是，通知零碎我要关注一个连贯的事件，如果有连贯事件就调用我注册的这个回调函数，回调函数中获取到客户端的连贯，而后再次注册一个read申请，通知零碎，如果有可读的数据就调用我注册的这个回调函数！当存在数据的时候，执行read回调，并写出数据！
为什么Netty应用NIO而不是AIO？
在Linux零碎上，AIO的底层实现仍应用Epoll，没有很好实现AIO，因而在性能上没有显著的劣势，而且被JDK封装了一层不容易深度优化，Linux上AIO还不够成熟。Netty是异步非阻塞框架，Netty在NIO上做了很多异步的封装。简略来说，当初的AIO实现比拟鸡肋！