但是，回过头想一想，上述的解决方案，存在一个问题。那就是系统并发量受限于线程池的线程数。如果请求只有几百的并发，那么上述的解决方案没有任何问题。但是任何一个稍有规模的业务场景都不会只有几百的并发。那么如果不对技术进行升级，只有两个办法。一个升级硬件配置，尤其是内存（因为线程是非常消耗内存的），另一方面将连接按照一定的逻辑维度进行拆分（比如按照业务场景）。
我曾经和我的Boss谈话时，提到这么一句话：技术的非常熟练，不如技术升级带来的价值高（因为我们公司有一个去年毕业的开发，非常抗拒学习新技术。虽然基础的CRUD挺熟练的，但是效率真的太低了。一个简单的条件查询就说要十五个工作日。如果他会使用函数式编程，配合MP，也许就一个小时吧。有空可以出个效率编程的专题，感觉很有价值）。
所以，在BIO越加疲软的时候（当然有的业务场景BIO性能貌似并不比NIO低多少，但是投入差别有些大），终于NIO面世。
NIO借助事件监听机制，提供非阻塞式的高伸缩性网络。当然，有兴趣的可以深挖，相关概念还是很多的，比如它与linux的IO模型的关系，这些都可以很好地帮助大家扩展视野（毕竟视野决定了高度）。
NIO有三大支柱，分别是：ByteBuffer，Channel，Selector（详见：Java NIO：Buffer、Channel 和 Selector）。
ByteBuffer：就是一个数据实体，其中提供了许多数据转换的方法。如在BIO的demo中就用到了