一直都说NIO相对BIO来说可以处理更高的并发链接，但是觉得NIO处理高并发的链接，也只是接受了tcp链接而已，是qps，等待处理的任务还是放在“事件队列”当中，等待后面的“业务线程池”处理，虽然说qps高，但是tps仍然受制于后面的业务线程池，所以对于“客户端”来说，NIO虽然是握手成功了，但是仍然是阻塞在那里，客户端也是等待！所以，NIO的优势在哪里呢？如下图：图1是NIO，图2是BIO。

图1

图2

你已经知道是提升的是“并发”能力了，那又跟处理“速度”有啥关系呢？

确实像你说的，对于客户端来说客户端都是等。但“等”跟“等”是不一样的，就像银行取号机，就这一台，假设说这取号机你点了取号按钮以后 2s 才能吐出一张纸，你自己捋一捋 BIO/NIO 场景下有一百个人的话总共需要多少秒能全部拿到号？

省下的是取号本身的时间，至于你取完号你到柜台去办理业务了，柜台给你办多久你能离开银行了，跟取号机是 BIO/NIO 有啥关系呢？

BIO是同步阻塞的，客户端在请求数据的过程中需要保持同一个连接；而NIO是同步非阻塞的，客户端在请求数据的过程中不需要保持同一个连接，即是轮询的方式实现的；所以区别在于一个请求是否需要保持同一个连接。

单从客户端请求与服务端连接连接来看，NIO确实不比BIO有优势，但一个请求处理简单来说可以分为两步：建立连接、服务端处理数据。假如一个请求建立连接需要1s和1MB内存,然后等待数据处理返回需要4s，对于BIO来说，5s内占用的内存都是1MB，100个请求就需要500MB;而对于NIO来说，假如一个轮询持续1s，然后下一次轮询间隔也是1s，第1s处理100个请求连接需要500MB，第2s没有连接0MB，第3s处理100个连接500MB，第4s没有连接0MB，第5s开始处理返回所以请求结果，平均下来只需要250MB，换个角度就是接收200个请求500MB，NIO的容纳量比BIO高了一倍。

所以NIO比BIO性能更好，优势在于NIO节约了“始终保持一个连接”的内存消耗。

图中好处主要是下面
1.nio只保持有限线程来接受请求，有限工作线程处理业务。同时把请求交给工作线程后又可以接受新请求了。所以这个线程一直存活
2.池化的bio每次请求需要创建一个线程，一般不能无限资源会耗尽，而且应该是同步等待返回的。最后回收到线程池

再讲讲你画的bio图 其实不是完全意义上bio的。比如你引入了等待队列，也就是说整个bio把任务交给等待队列就应该结束了。
Nio也不是完全的nio 而是react模型。

本质上的nio应该是只看多路复用 bio是堵塞 不是你画的图