• 【OS】I/O多路复用的一点理解


    为什么会有I/O多路复用

    首先,要知道I/O是什么,I/O == copy数据,由内往外,由外往内 来回Copy数据
    copy 数据由 进程内存空间 —>操作系统内部 —> 外部设备 就是输出,反过来就是输入

    进程在I/O操作时会发生什么?

    但是由于I/O操作中外设的速度相对于内存的速度较慢, 进程不得不等待外部设备把数据拿过来,这会导致进程被挂起,整个程序停止执行,这样根本不可行。

    如果使用线程来处理I/O可行吗?

    在进行IO操作,线程同样会被阻塞,但不影响别的线程继续处理新的请求,整体上,程序依然可以正常执行,这样看上去是可行的,-但是面对大量的I/O请求?还行吗?可能你会说,可以创建更多的线程来处理,当然可以,但是,大量的线程是要耗费大量的内存(再加上很多线程都被阻塞,那一部分属于现成的内存,根本就没有使用到,白白浪费),同时维护和切换线程执行都会导致系统性能下降。
    所以也不可行。
    那该怎么办?

    能不能实现一个线程 既能处理大量的I/O操作,又不会阻塞,继续接受新的请求呢?

    当然是有的,答案就是通过I/O多路复用来实现。
    一个线程在面对大量的I/O操作时,将对应的文件标识符交给操作系统,没有数据可读时,线程不会阻塞在这里,而是继续处理新来的请求,而操作系统会帮忙监控这这些文件标识符,如果有文件可读时,再去通知线程来处理。

    Linux操作系统中,I/O多路复用的方式,主要有三种 select poll epoll,具体的实现细节不同,这里不再详细介绍,只做简单总结
    select 支持有限的监控文件标识符的数量,使用数组存储,由进程空间拷贝到操作系统内核空间,有数据可读时,只是通知线程,但没有告诉线程是哪一个文件
    poll 底层使用链表存储文件标识符,只解决了数量限制问题
    epoll 通过共享内存方式,解决copy 文件标识符的问题,通过红黑树底层数据结构,通知到具体的线程以及需要操作的文件标识符(进行I/O处理的不止只有一个线程,因此还定位到了线程)

    文件标识符:就是来标志文件的,通过文件标识符,线程能够读取,写入数据到对应的文件。这与Linux操作系统所宣扬的:一切皆文件,相对应。

  • 相关阅读:
    小白学流程引擎-FLowable(二) — 从零搭建自己的FLowable服务 — 搭建流程服务-FLowable的新手指南
    如何遍历collections.OrderedDict,服了又忘记items
    C++11标准模板(STL)- 算法(std::reverse)
    二、.Net Core搭建Ocelot
    requests从一个链接下载存放在临时文件tempfile,python
    React 自定义hook 之 防抖和节流
    【从0-1成为架构师】高可用架构
    UE5----使用C++的项目重新打开后东西丢失
    Linux常用命令
    spring容器
  • 原文地址:https://blog.csdn.net/weixin_45919793/article/details/125496629