第11讲 | Java提供了哪些IO方式？ NIO如何实现多路复用？

批评NIO确实要小心，我觉得主要是三方面，首先是如果是从写BIO过来的同学，需要有一个巨大的观念上的转变，要清楚网络就是并非时刻可读可写，我们用NIO就是在认真的面对这个问题，别把channel当流往死里用，没读出来写不进去的时候，就是该考虑让度线程资源了，第二点是NIO在不同的平台上的实现方式是不一样的，如果你工作用电脑是win，生产是linux，那么建议直接在linux上调试和测试，第三点，概念上的，理解了会在各方面都有益处，NIO在IO操作本身上还是阻塞的，也就是他还是同步IO，AIO读写行为的回调才是异步IO，而这个真正实现，还是看系统底层的，写完之后，我觉得我这一二三有点凑数的嫌疑

忘记回答问题了。所以对于多路复用IO，当出现有的IO请求在数据拷贝阶段，会出现由于资源类型过份庞大而导致线程长期阻塞，最后造成性能瓶颈的情况

据我理解，NIO2的局限性在于，如果回调时客户端做了重操作，就会影响调度，导致后续的client回调缓慢

这里Nio的Selector只注册了一个sever chanel，这没有实现多路复用吧，多路复用不是注册了多个channel ，处理就绪的吗？而且处理客户端请求也是在同线程内，这还不如上面给的Bio解决方案吧

java nio的selector主要的问题是效率，当并发连接数达到数万甚至数十万的时候 ，单线程的selector会是一个瓶颈；另一个问题就是再线上运行过程中经常出现cpu占用100%的情况，原因也是由于selector依赖的操作系统底层机制bug 导致的selector假死，需要程序重建selector来解决，这个问题再jdk中似乎并没有很好的解决，netty成为了线上更加可靠的网络框架。不知理解的是否正确，请老师指教。

看nio代码部分，请求接受和处理都是一个线程在做。这样的话，如果有多个请求过来都是按顺序处理吧，其中一个处理时间比较耗时的话那所有请求不都卡住了吗？如果把nio的处理部分也改成多线程会有什么问题吗

我也自己写过一个基于nio2的网络程序，觉得配合futrue写起来很舒服。 仓库地址：https://github.com/LoranceChen/RxSocket 欢迎相互交流开发经验～ 记得在netty中，有一个搁置的netty5.x项目被废弃掉了，原因有一点官方说是性能提升不明显，这是可以理解的，因为linux下是基于epoll，本质还是select操作。 听了课程之后，有一点印象比较深刻，select模式是使用一个线程做监听，而bio每次来一个链接都要做线程切换，所以节省的时间在线程切换上，当然如果是c/c++实现，原理也是一样的。 想问一个一直困惑的问题，select内部如何实现的呢？ 个人猜测：不考虑内核，应用层的区分，单纯从代码角度考虑，我猜测，当select开始工作时，有一个定时器，比如每10ms去检查一下网络缓冲区中是否有tcp的链接请求包，然后把这些包筛选出来，作为一个集合（即代码中的迭代器）填入java select类的一个集合成员中，然后唤醒select线程，做一个while遍历处理链接请求，这样一次线程调度就可以处理10ms内的所有链接。与bio比，节省的时间在线程上下文切换上。不知道这么理解对不对。 另外，也希望能出一个课程，按照上面这种理解底层的方式，讲讲select（因为我平常工作在linux机器，所以对select epoll比较感兴趣）如何处理read，write操作的。谢谢～

作者对同步/异步， 阻塞/非阻塞的概念说明存在问题。 《操作系统（第9版）》中关于进程通信中有对这部分概念做过解释， 在进程间通信的维度， 同步和阻塞，异步和非阻塞是相同的概念。 沿着作者的概念解释简单推论一下就可以发现: 如果同步操作是需要等待调用返回才能进行下一步， 显然这个调用是阻塞的。 反之， 不需要等待调用返回的接口，必然需要提供事件， 回调等机制，这种调用显然是非阻塞的。

还有一个问题请教，select在单线程下处理监听任务是否会成为瓶颈？能否通过创建多个select实例，并发监听socket事件呢？

杨老师，有个问题一直不太明白：BufferedInputStream和普通的InputStream直接read到一个缓冲数组这两种方式有什么区别？