Python站
  • 说明
  • 源码分析
  • 100 系列
  • python
    • 开发基础
      • 数据类型
      • 字符编码
      • 文本操作
      • 玩转Python100解
    • 函数编程
      • 装饰器
      • 内置函数
        • vars
      • 内置模块
        • enum
        • os
        • argparse
        • importlib
        • shelve
        • collections
        • re
      • 神奇三方
        • setuptools
        • celery
    • 面向对象
      • 面向对象100解(草稿)
    • 网络编程
      • 网络理论知识
      • 网络编程socket
      • socketserver源码泛读
    • 并发编程
      • 并发编程之多进程
        • 子进程基本使用
        • 进程的属性或方法
        • 守护进程
        • 互斥锁
        • 队列
        • 生产者消费者模型
      • 并发编程之多线程
        • 子线程基本使用
        • GIL全局解释器锁
        • 死锁现象与递归锁
        • 信号量事件定时器
        • 线程队列queue
      • 并发编程之进程线程池
      • 并发编程之协程
      • 并发编程之IO模型
        • 阻塞IO
        • 非阻塞IO
        • 多路复用IO
        • 异步IO
        • IO模型比较分析
    • 数据库说
      • mongoengine源码精读
    • 前端开发
    • 后端开发
      • flask源码精读
      • django源码精读
        • 01 软件打包与部署
        • 02 python调试工具 pdb
        • 03 创建一个django项目
    • 爬虫相关
      • Jupyter Notebook
      • urllib
      • urllib3源码泛读
      • 数据解析
      • requests源码精读
        • 初始化说 __init__.py
        • 版本信息 __version__.py
        • 版本兼容 compat.py
        • 经典视图 api.py
        • 逻辑实现 sessions.py
        • 数据存储 models.py
        • 网络传输 adapters.py
        • 异常结构 exceptions.py
        • 交互协定 status_code.py
        • 钩子编程 hooks.py
        • 数据结构 structures.py
        • 辅助输出 utils.py
        • 安全认证 auth&certs.py
    • 编程思想
      • 算法
      • 数据结构
      • 设计模式
        • 简单工厂模式
        • 工厂方法模式
        • 抽象工厂模式
        • 建造者模式
        • 单例模式
        • 适配器模式
        • 桥模式
        • 组合模式
        • 外观模式
        • 代理模式
        • 责任链模式
        • 观察者模式
        • 策略模式
        • 模板方法模式
      • Python技巧100解
      • Effective Python
    • 企业应用
      • DevOps
      • Web服务-Nginx
      • 网站发布
      • 源码管理
        • Git
        • GitHub
        • GitLab
      • Golang
      • Docker
      • Ubuntu
    • 项目实战
    • 就业相关
    • 其他爱好
      • 科技单词100解答
Powered by GitBook
On this page
  1. python
  2. 并发编程
  3. 并发编程之IO模型

阻塞IO

Blocking IO

Previous并发编程之IO模型Next非阻塞IO

Last updated 5 years ago

在linux中,默认情况下所有的socket都是blocking,一个典型的读操作流程大概是这样:

  • 用户进程调用了recvfrom这个系统调用

  • 内核就开始了IO的第一个阶段:准备数据。对于Network IO来说,很多时候数据在一开始还没有到(比如,还没有收到一个完整的UDP包),这个时候内核就要等待足够的数据到来

  • 在用户进程这边,整个进程会被阻塞

  • 当内核一直等到数据准备好了,它就会将数据从内核中拷贝到用户内存, 然后内核返回结果

  • 用户进程才解除block的状态,重新运行起来

所以,Blocking IO的特点就是在IO执行的两个阶段(等待数据和拷贝数据两个阶段)都被block

几乎所有的程序员第一次接触到的网络编程都是从listen()、send()、recv() 等接口开始的,使用这些接口可以很方便的构建服务器/客户机的模型,然而大部分的socket接口都是阻塞型的,如下图:

PS:所谓阻塞型接口是指系统调用(一般是IO接口)不返回调用结果并让当前线程一直阻塞,只有当该系统调用获得结果或者超时出错时才返回。

实际上,除非特别指定,几乎所有的IO接口 ( 包括socket接口 ) 都是阻塞型的。这给网络编程带来了一个很大的问题,如在调用recv(1024)的同时,线程将被阻塞,在此期间,线程将无法执行任何运算或响应任何的网络请求。

一个简单的解决方案:

在服务器端使用多线程(或多进程)
多线程(或多进程)的目的是让每个连接都拥有独立的线程(或进程)这样任何一个连接的阻塞都不会影响其他的连接

该方案的问题是:

开启多进程或都线程的方式,在遇到要同时响应成百上千路的连接请求,
则无论多线程还是多进程都会严重占据系统资源,
降低系统对外界响应效率,而且线程与进程本身也更容易进入假死状态

改进方案:

很多程序员可能会考虑使用“线程池”或“连接池”
- “线程池”旨在减少创建和销毁线程的频率,其维持一定合理数量的线程,并让空闲的线程重新承担新的执行任务
- “连接池”维持连接的缓存池,尽量重用已有的连接、减少创建和关闭连接的频率。
这两种技术都可以很好的降低系统开销,都被广泛应用很多大型系统,如websphere、tomcat和各种数据库等

改进后方案其实也存在着问题:

“线程池”和“连接池”技术也只是在一定程度上缓解了频繁调用IO接口带来的资源占用
而且,所谓“池”始终有其上限,当请求大大超过上限时,“池”构成的系统对外界的响应并不比没有池的时候效果好多少。
所以使用“池”必须考虑其面临的响应规模,并根据响应规模调整“池”的大小。

对应上例中的所面临的可能同时出现的上千甚至上万次的客户端请求,“线程池”或“连接池”或许可以缓解部分压力,但是不能解决所有问题。总之,多线程模型可以方便高效的解决小规模的服务请求,但面对大规模的服务请求,多线程模型也会遇到瓶颈,可以用非阻塞接口来尝试解决这个问题。