我对NIO的理解
来源:互联网 发布:软件接口设计 编辑:程序博客网 时间:2024/04/29 05:26
NIO解决了两个阻塞问题:(1)IO本身的阻塞 (2)sockect.的accept阻塞;解决方案分别是新IO里面的channel/bytebuffer和selector.
问题1:
首先传统的IO是基于流的,是阻塞的,因为假设在网络应用中,如果数据没有到位(没有数据,或者不够:例如一个字节只传了第一位),而又不是流的结束(连接中断),那么这个时候read会阻塞至数据够了或者流结束或者有异常。
因此换句话说:必须读到数据,要不只能等到异常或者socket关闭返回-1,没有返回0的情况;
而新IO,可以读不到数据,可以返回0,只有等异常或者socke关系返回-1。因此不用阻塞线程。
换句话说:在socket不关闭情况下,传统IO必须读到数据,否则阻塞,而新IO可以不读到数据返回0从而不阻塞。
那么假设我们用装饰类bufferinputstream之类,是否解决了这个问题呢?其实并没有,因为理由有2个:
(1)装饰肯定以原来的inputstream为基础,既然基础的是阻塞的,那么必然也是阻塞的;
(2)例如BufferedReader.readline(),只是等于数据满足一行(遇到换行符)时,才会读出,减少不断读的代价,反而增大了要求;
从上面可以看出,传统的IO是阻塞的,那么只能借助于NIO来解决这个问题:
NIO用通道(这样仅仅是数据而已了)取代了流(字节流或者字符流),最大的特性是无阻塞的,即通道里面有多少数据就读写多少,立即返回,而不是阻塞。
(1)即使数据没有全部到位,也可以读写。
问题2:
select()是阻塞的,监听信道注册的感兴趣IO集发生事情(通道有读的数据,特别注意监听写的时候,是随时可以写的,取决于自己);
channel可以注册多个感兴趣IO ,对应不同的KEY,
当执行SELECT后,在执行selectkeys()就会把发生的IO事情选取出来做掉,记住做完之后要REMOVE,否则下次发生新事件,是在老的事情基础上增加的
因为从这个角度看,
NIO核心是SELECT,屏蔽了一个线程一个连接的缺点:假设都是长连接且用户过大,导致线程过多;
同时READ/WRITE是无阻塞的,配合SELECT就解决了死等现象;
遗留一个问题:假设NIO选择READ后,我读是否直接用等于0标记读数据结束了??
不知道自己理解的对不对?
- 我对NIO的理解
- 对 java.nio.ByteBuffer 的粗浅理解
- 我所理解的Java NIO
- 我对SOA的理解我对SOA的理解
- 我对COM的理解
- 我对事件的理解
- 我对SOA的理解
- 我对SOA的理解
- 我对SOA的理解
- 我对ERP的理解
- 我对JSP的理解
- 我对字符集的理解
- 我对webservice的理解
- 我对SOA的理解
- 我对MMU的理解
- 我对黑客的理解
- 我对servlet的理解
- 我对CSS的理解
- 关于开发 可以多想,但前期一定不要多做
- Android模拟器中各种屏幕分辨率
- HTTP POSTs and HTTP GETs with WebClient
- Oracle and Direct I/O
- java io 流原理
- 我对NIO的理解
- Android 重要的组件
- 创建Android启动界面
- 欢迎大家一起as3.0 or flex 研究
- Activity与Service通过广播交换复杂对象数据用法详解
- Java应用程序模拟向Servlet发送POST请求
- Redmine: 按照用户角色限定问题单流程
- 《当程序员的那些狗日日子》(五十五)另一种生存之道
- 我对DX11的理解和简化框架与快速游戏制作(续1)