模型解释：
NIO场景下，客户端（Client）发起请求，服务端接收请求后，并不是直接分配业务线程处理这次请求，而是交给专门的IO线程（JAVA 中的Selector）读取请求流，当数据准备好以后，才会交给业务线程执行业务逻辑，最后交给IO线程写入响应流。
到这里，读者可能会有两个疑问？NIO模型下，IO线程会成为瓶颈？NIO解决了什么问题（与BIO相比）？
IO线程会成为瓶颈吗？这个问题得从IO线程的底层实现说起，NIO之所以是同步非阻塞，就是因为底层操作系统支持同步非阻塞，JVM只是通过系统调用本地方法实现同步非阻塞的（本质上是操作系统实现同步非阻塞，而JVM只是通过本地方法执行系统调用而已）。linux系统提供了epoll系统调用，epoll是基于事件驱动方式来实现的（也就是说，底层操作系统准备好了数据，以事件驱动的机制回调通知），而NIO中的Selector的select（）方法调用，是通过本地方调用epoll系统调用来实现非阻塞的，最大限度利CPU时间片，所以IO线程的瓶颈也就是硬件瓶颈。
NIO解决了什么问题？
通过单独的IO线程，当有可读、可写的事件发生的时候再去做读写操作，这个时候就不用像BIO那样一直阻塞等待在那，业务线程就可以被释放出来做更多的事情。说白了，提高了CPU利用率，让更少的线程做更多的事。
