62,614
社区成员
发帖
与我相关
我的任务
分享我对NIO的理解
NIO解决了两个阻塞问题：（1）IO本身的阻塞 （2）sockect.的accept阻塞；解决方案分别是新IO里面的channel/bytebuffer和selector.
问题1：
首先传统的IO是基于流的，是阻塞的，因为假设在网络应用中，如果数据没有到位（没有数据，或者不够：例如一个字节只传了第一位），而又不是流的结束（连接中断），那么这个时候线程会阻塞。
那么假设我们用装饰类bufferinputstream之类，是否解决了这个问题呢？其实并没有，因为理由有2个：
（1）装饰肯定以原来的inputstream为基础，既然基础的是阻塞的，那么必然也是阻塞的；
（2）例如BufferedReader.readline(),只是等于数据满足一行（遇到换行符）时，才会读出，减少不断读的代价，反而增大了要求；
从上面可以看出，传统的IO是阻塞的，那么只能借助于NIO来解决这个问题：
NIO用通道（这样仅仅是数据而已了）取代了流（字节流或者字符流），最大的特性是无阻塞的，即通道里面有多少数据就读写多少，立即返回，而不是阻塞。
（1）即使数据没有全部到位，也可以读写。
问题2：
然后通过selector来监听通道收听感兴趣的数据，如果有数据，这个时候可以去读或者写，这样解决了ACCEPT的阻塞：
（1）不用像传统的那样去死等数据来，监听到才通知读；
不知道自己理解的对不对？
问题1：
首先传统的IO是基于流的，是阻塞的，因为假设在网络应用中，如果数据没有到位（没有数据，或者不够：例如一个字节只传了第一位），而又不是流的结束（连接中断），那么这个时候线程会阻塞。
那么假设我们用装饰类bufferinputstream之类，是否解决了这个问题呢？其实并没有，因为理由有2个：
（1）装饰肯定以原来的inputstream为基础，既然基础的是阻塞的，那么必然也是阻塞的；
（2）例如BufferedReader.readline(),只是等于数据满足一行（遇到换行符）时，才会读出，减少不断读的代价，反而增大了要求；
从上面可以看出，传统的IO是阻塞的，那么只能借助于NIO来解决这个问题：
NIO用通道（这样仅仅是数据而已了）取代了流（字节流或者字符流），最大的特性是无阻塞的，即通道里面有多少数据就读写多少，立即返回，而不是阻塞。
（1）即使数据没有全部到位，也可以读写。
问题2：
然后通过selector来监听通道收听感兴趣的数据，如果有数据，这个时候可以去读或者写，这样解决了ACCEPT的阻塞：
（1）不用像传统的那样去死等数据来，监听到才通知读；
不知道自己理解的对不对？
...全文
请发表友善的回复…
发表回复
shaosijun2004 2011-10-31
- 打赏
- 举报
学习。
有了selector 就不需要写多个server
selector可以同时绑定多个port
还有
NIO 通信用的channel、directBuffer是直接和操作系统交互的，性能要高很多
且channel传输数据不是以流的形式，是以块的形式传递，比流要高速度
因为对于操作系统的存储是块存储的，块操作更贴近操作系统的实现
有了selector 就不需要写多个server
selector可以同时绑定多个port
还有
NIO 通信用的channel、directBuffer是直接和操作系统交互的，性能要高很多
且channel传输数据不是以流的形式，是以块的形式传递，比流要高速度
因为对于操作系统的存储是块存储的，块操作更贴近操作系统的实现
宅男小何 2011-10-31
- 打赏
- 举报
nio其实应该是个轮循，:-)
我嘞个去 2011-10-31
- 打赏
- 举报
我是来学习NIO的！
aaaa8215 2011-10-31
- 打赏
- 举报
nio处理大文件的分批读取 效率不错
kiss601459202 2011-10-31
- 打赏
- 举报
看来是散分贴 学习&&接分
