熟悉网络编程的同学可能听过BIO、NIO网络模型。本篇文章作为Netty系列开篇，先从总体介绍下以上两种网络I/O模型。
BIO
BIO(Blocking I/O)，阻塞网络I/O。在JDK1.4之前，建立网络连接采用的就是BIO模型。这种模型需要先在服务端启动ServerSocket，客户单启动Socket和服务端进行通行。服务端会建立一线程池等待请求，客户端发送请求后，先咨询服务端是否有线程可用，没有则一直等待或遭到拒绝请求，有的话服务端会分配一个线程处理客户端访问请求，待客户端访问结束后，服务端线程回归线程池。
从上面代码可以看到BIO网络通信为每次socket连接会新建一个线程，进行业务逻辑处理。服务端线程数和客户端线程数是1:1的正比关系。这种模型的弊端是无法支撑大并发量，如果客户端并发访问增多，需要更多的服务器线程来提供服务，而过多的线程会消耗服务器资源，并且频繁的线程切换反而会影响处理性能和速度。tomcat 启动时如果日志显示Starting ProtocolHandler ["http-bio-8080"]，则使用的是就是这种模式。
NIO
NIO(Non-blocking I/O），非阻塞网络I/O。基于事件驱动思想，主要是解决BIO无法支撑大并发问题。NIO基于Reactor，当socket有流可读或可写入socket时，会通知应用程序进行处理。这时不再是一个连接就要对应一个处理线程，而是当有有效的请求，对应一个线程，当连接没有数据时，就没有工作线程来处理。当一个连接创建后，不需要对应一个线程，这个连接会被注册到多路复用器上，所有的连接只需要一个线程就可以搞定，该线程的多路复用器进行轮询，发现连接上有请求时，开启一个线程进行处理，这个多路复用器注册的连接会被这一个线程来处理，当众多连接中某个连接请求处理时有等待阻塞时，也会碰到BIO的问题。
BIO与NIO的不同体现在使用BIO时往往会引入多线程，每个连接及处理是一个单独线程，而NIO使用单线程或者只使用少量多线程来处理连接和网络请求，真正的处理是后台的单独线程，这样设计的好处可以减小服务端的网络压力，当客户端有数据时才进行网络连接和数据处理，提高来系统的并发性。
如上图可以看到，NIO的主要组件包括：缓冲区Buffer、通道Channel、多路复用器Selector。在NIO库中，所有数据都是用缓冲区Buffer处理。在读取数据时，直接读取到缓冲区中，在写入数据时，写入缓冲区，任何时候访问NIO中的数据，都是通过缓冲区进行的，具体缓冲区的类型后面介绍。Channel是一个通道，网络数据通过Channel进行读取和写入，通道和流的不同之处在于通道是双向的，是全双工的，可以用于读、写或同时进行读写，而流只能在一个方向是流动，可以充分利用网络。Selector用于选择已经就绪的通道能力，通道状态包括：channel connect、channel active、channel read、channel write等，当通道触发以上状态，会被Selector轮询出来，通过SelectionKey获取就绪channel集合，再进行后续IO操作。
上面程序是将ServerSocketChannel设置为非阻塞模型，将ServerSocketChannel注册到selector，监听SelectionKey.OP_ACCEPT事件。
在while循环中循环遍历selector，休眠事件是1s，无论是否有读写事件发生，selector每隔1s被唤醒一次，当有处于就绪状态的channel时，select会返回该Channel的SelectionKey集合，通过遍历迭代集合，进行网络的异步读写。
上面程序是根据Key的操作位判断获悉的网络事件。如果key是accept事件，这表示服务端接受了客户端的连接。需要将客户端channel注册到selector多路复用选择器，请给将read事件绑定到selector中。如果key是read事件，表示客户端有数据发送给服务端，这时服务端需要获取key对应的channel，将客户端发送的数据存储到缓冲区buffer，获取到数据进行编码后就可以看到客户端发送到数据内容。
总结
本文介绍了BIO和NIO两种网络编程模型架构的不同和部分代码实现。NIO引入channel和Selector等模型组件实现网络多路复用和高效利用，当channel处于selector监控事件状态服务端才会作出应对，这样避免了一个客户端连接绑定一个服务端线程，只有当客户端准备好数据服务端才会分配线程进行处理，提升服务端处理的并发量。
