• 什么是IO多路复用


    先百度或者知乎,找到这篇文章 [1] IO 多路复用是什么意思?

     

    文中提到:

      

    第一种好理解,就是来一个请求,fork一个进程,第二种提到I/O多路复用使用单个线程实现的,作者肯定没有写错,因为后面的文章也都是写的线程,我的问题是为什么不是进程来管理?参考文章[2] 里面的code 给出的是通过一个进程来服务多个client 连接请求. 我理解这是通过单进程的里面的一个线程来处理的,所以这里进程线程就不作区分.
     
    还有,下面引文中一个问题问的很好
    Q: 
    那这样子,在读取socket1的数据时,如果其它socket有数据来,那么也要等到socket1读取完了才能继续读取其它socket的数据吧。那不是也阻塞住了吗?而且读取到的数据也要开启线程处理吧,那这和多线程IO有什么区别呢?
     
    因为的答案很清楚了,加一些自己的理解,I/O多路复用解决了用单进程/线程 服务多个请求的问题,但是加入多个请求的read或者write 都ready了,还是一个一个轮流处理的,这时我们自然想到用多线程来处理多个请求,但是如果CPU是单核的还是体现不了多线程的优势,必须是多核CPU才行.

      

    这里摘录一些精彩回复  


    作者:罗志宇
    链接:https://www.zhihu.com/question/32163005/answer/55772739
    来源:知乎
    著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

    select, poll, epoll 都是I/O多路复用的具体的实现,之所以有这三个鬼存在,其实是他们出现是有先后顺序的。

    I/O多路复用这个概念被提出来以后, select是第一个实现 (1983 左右在BSD里面实现的)。

    select 被实现以后,很快就暴露出了很多问题。
    • select 会修改传入的参数数组,这个对于一个需要调用很多次的函数,是非常不友好的。
    • select 如果任何一个sock(I/O stream)出现了数据,select 仅仅会返回,但是并不会告诉你是那个sock上有数据,于是你只能自己一个一个的找,10几个sock可能还好,要是几万的sock每次都找一遍,这个无谓的开销就颇有海天盛筵的豪气了。
    • select 只能监视1024个链接, 这个跟草榴没啥关系哦,linux 定义在头文件中的,参见FD_SETSIZE。
    • select 不是线程安全的,如果你把一个sock加入到select, 然后突然另外一个线程发现,尼玛,这个sock不用,要收回。对不起,这个select 不支持的,如果你丧心病狂的竟然关掉这个sock, select的标准行为是。。呃。。不可预测的, 这个可是写在文档中的哦.

    “If a file descriptor being monitored by select() is closed in another thread, the result is unspecified”
    霸不霸气

    于是14年以后(1997年)一帮人又实现了poll, poll 修复了select的很多问题,比如
    • poll 去掉了1024个链接的限制,于是要多少链接呢, 主人你开心就好。
    • poll 从设计上来说,不再修改传入数组,不过这个要看你的平台了,所以行走江湖,还是小心为妙。

    其实拖14年那么久也不是效率问题, 而是那个时代的硬件实在太弱,一台服务器处理1千多个链接简直就是神一样的存在了,select很长段时间已经满足需求。

    但是poll仍然不是线程安全的, 这就意味着,不管服务器有多强悍,你也只能在一个线程里面处理一组I/O流。你当然可以那多进程来配合了,不过然后你就有了多进程的各种问题。

    于是5年以后, 在2002, 大神 Davide Libenzi 实现了epoll.

    epoll 可以说是I/O 多路复用最新的一个实现,epoll 修复了poll 和select绝大部分问题, 比如:
    • epoll 现在是线程安全的。
    • epoll 现在不仅告诉你sock组里面数据,还会告诉你具体哪个sock有数据,你不用自己去找了。 

    作者:Leslie
    链接:https://www.zhihu.com/question/32163005/answer/76577586
    来源:知乎
    著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

    要弄清问题 先要知道问题的出现原因
    原因:
    由于进程的执行过程是线性的(也就是顺序执行),当我们调用低速系统I/O(read,write,accept等等),进程可能阻塞,此时进程就阻塞
    在这个调用上,不能执行其他操作.阻塞很正常. 接下来考虑这么一个问题:
    一个服务器进程和一个客户端进程通信,服务器端read(sockfd1,bud,bufsize),此时客户端进程没有发送数据,那么read(阻塞调用)将阻塞直到客户端调用write(sockfd,but,size)发来数据. 在一个客户和服务器通信时这没什么问题,当多个客户与服务器通信时,若服务器阻塞于其中一个客户sockfd1,当另一个客户的数据到达套接字sockfd2时,服务器不能处理,仍然阻塞在read(sockfd1,...)上;此时问题就出现了,不能及时处理另一个客户的服务,咋么办?I/O多路复用来解决!
    I/O多路复用:
    继续上面的问题,有多个客户连接,sockfd1,sockfd2,sockfd3..sockfdn同时监听这n个客户,当其中有一个发来消息时就从select的阻塞中返回,然后就调用read读取收到消息的sockfd,然后又循环回select阻塞;
    这样就不会因为阻塞在其中一个上而不能处理另一个客户的消息

    Q:
    那这样子,在读取socket1的数据时,如果其它socket有数据来,那么也要等到socket1读取完了才能继续读取其它socket的数据吧。那不是也阻塞住了吗?而且读取到的数据也要开启线程处理吧,那这和多线程IO有什么区别呢?

    A:
    1.CPU本来就是线性的 不论什么都需要顺序处理 并行只能是多核CPU
    多路复用本来就是用来解决对多个I/O监听时,一个I/O阻塞影响其他I/O的问题,跟多线程没关系.
    3.跟多线程相比较,线程切换需要切换到内核进行线程切换,需要消耗时间和资源. 而I/O多路复用不需要切换线/进程,效率相对较高,特别是对高并发的应用nginx就是用I/O多路复用,故而性能极佳.但多线程编程逻辑和处理上比I/O多路复用简单.而I/O多路复用处理起来较为复杂.
     

     作者:匿名用户
    链接:https://www.zhihu.com/question/32163005/answer/55687802
    来源:知乎
    著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。 
     
    这些名词比较绕口,理解涵义就好。一个epoll场景:一个酒吧服务员(一个线程),前面趴了一群醉汉,突然一个吼一声“倒酒”(事件),你小跑过去给他倒一杯,然后随他去吧,突然又一个要倒酒,你又过去倒上,就这样一个服务员服务好多人,有时没人喝酒,服务员处于空闲状态,可以干点别的玩玩手机。至于epoll与select,poll的区别在于后两者的场景中醉汉不说话,你要挨个问要不要酒,没时间玩手机了。io多路复用大概就是指这几个醉汉共用一个服务员。
     



     
    select(),poll(),epoll() 都是I/O多路复用的机制。I/O 多路复用通过一种机制,可以监视多个描述符,一旦某个描述符就绪(一般是读就绪或者写就绪,就是这个文件描述符进行读写操作之前),能够通知程序进行相应的读写操作。但select(),poll(),epoll() 本质上都是同步 I/O,因为他们都需要在读写事件就绪后自己负责进行读写,也就是说这个读写过程是阻塞的,而异步 I/O 则无需自己负责进行读写,异步 I/O 的实现会负责把数据从内核拷贝到用户空间。
     
     
    看了上面的介绍,原理是懂了,但是具体细节不太懂,直到遇到了参考文章[2],才通透了许多
     
    ref:
    转载请注明出处 http://www.cnblogs.com/mashuai-191/
  • 相关阅读:
    【学习】Filter
    黑马程序员JAVA基础String 类(上)
    黑马程序员JAVA基础基本数据类型对象包装类
    [xcode]安装xcode出现一个错误:The Installation Failed.
    [SW]SolidWorks文件属性(Properties)
    AutoCAD:使用VS2012调试AutoCAD 2010中.Net DLL类库
    AutoCAD:ObjectARX所有版本下载地址
    [IOS]如何让手上的 iPhone 或 iPad 进入 DFU 或 Recovery 模式
    [iOS]Win8下iTunes无法连接iPhone版本的解决方法
    [SW]SolidWorks API SDK二次开发学习心得01开发方式
  • 原文地址:https://www.cnblogs.com/mashuai-191/p/9638913.html
Copyright © 2020-2023  润新知