IO多路复用技术?
刚开始接触这个东西是在redis中,redis使用单线程处理,辅之以IO多路复用技术,查阅了很多的资料,都是
一知半解.
后来在研究一个名词NIO的时候发现,IO多路复用技术是从这里衍生出来的.
NIO,英文名称是NEW INPUT OUTPUT,俗家名称新式IO,顾名思义还有传统IO
NIO有三个名词:缓冲区 通道 Selector,理解了这三个名词基本上就知道啥意思了
先说下传统IO,举个例子,假设是一个read命令,线程将命令发送给内核后,这个线程会进入阻塞状态,因为数据不可能瞬间就
返回,有个数据准备阶段,这个阶段会很慢,比如从磁盘中寻找数据会非常慢,这时候线程阻塞了,会等好长的时间,性能上肯定是
非常差的,这个就类似于为啥要使用多线程。
在这种情况下NIO出现了,他是jdk1.4的产物,充分利用数据准备阶段的时间,因为这段时间还是漫长的,我们可以干很多的事情。
NIO
当线程向内核发送读命令之后,内核立刻返回,当然肯定不是返回数据了,数据还在准备中,线程收到返回之后呢继续去干其他的事情,
这个就把数据准备的时间利用起来了.
那么问题来了,数据准备好了咋办呢,我这还要返回给人家呢,调用方还等着数据呢。
这时候用了第一个名词,缓冲区,数据准备好了放在缓冲区里
第二个名词:通道,客户端跟服务器之间得建立连接吧,我得知道我数据准备好了发给谁吧。
第三个名词:selector 这个就类似于redis的哨兵模式,监视作用,线程发送read命令后,直接返回,后续数据准备好了,我还要发给调用方呢,
人家还嗷嗷待哺呢,我需要一个监听者,来监听,如果缓冲区里的数据准备好了,那就给监听者报告,说我数据准备好了,你可以给人家送过去了,
这时候监听者就从把数据从对应的通道传给调用方。监听者是用了一个for循环一直不停的循环,查看是不是有数据准备完毕,性能超级差,一直
轮询,因此这也是selector的缺点.而且他还有限制,能监听的通道数据最多只有1024个,而且还是线程不安全的。
进阶版:poll 放开了监听通道的数量,但是线程还是不安全的
高级版:epoll 线程安全