为什么说NIO能处理更高的并发链接?
一直都说NIO相对BIO来说可以处理更高的并发链接,但是觉得NIO处理高并发的链接,也只是接受了tcp链接而已,是qps,等待处理的任务还是放在“事件队列”当中,等待后面的“业务线程池”处理,虽然说qps高,但是tps仍然受制于后面的业务线程池,所以对于“客户端”来说,NIO虽然是握手成功了,但是仍然是阻塞在那里,客户端也是等待!所以,NIO的优势在哪里呢?如下图:图1是NIO,图2是BIO。
图1
图2
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
你已经知道是提升的是“并发”能力了,那又跟处理“速度”有啥关系呢?
确实像你说的,对于客户端来说客户端都是等。但“等”跟“等”是不一样的,就像银行取号机,就这一台,假设说这取号机你点了取号按钮以后 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是堵塞 不是你画的图