浅谈进程、线程、协程 概念 进程：计算机中的程序关于某数据集合的一次运行活动，是系统资源分配和调度的基本单位，是操作系统结构的基础。进程间切换开销比较大，但相对安全稳定。以前：进程是程序的基本执行单位。现在：进程是线程的容器。 进程是一个实体，每个进程都有对应的地址空间。一般包括：文本区域、数据区域、堆栈 文本区域：存储处理器执行的代码 数据区域：存储变量和进程执行期间使用的动态分配的内存 堆栈：存储活动过程调用的指令和本地变量 进程是一个活动的实体，执行中的程序。 线程：可以被称为轻量级的进程。线程是进程的一个实体，是CPU调用和分派的基本单位。线程不拥有系统资源，只有运行中必不可少的资源，但线程可以和他所属的进程共享进程所属的全部资源。每个线程有自己独立的上下文，切换受系统控制 。 线程是由线程ID、当前指令指针(PC)、寄存器集合和堆栈组成 线程的三种状态：就绪状态、执行状态、堵塞状态 协程：可以被称为用户态的轻量级线程。协程的调度完全由用户控制。协程拥有自己的寄存器上下文和栈。协程调度切换时，将寄存器上下文和栈保存到其他地方，切回是恢复先前保存的寄存器上下文和栈即可。可以不加锁的访问全局变量。所以协程切换非常快 区别 进程和线程的比较 地址空间：线程是进程内的执行单元，进程内至少由一个线程共享进程的地址空间，而进程由自己独立的地址空间 资源：进程是资源分配和拥有的单位，同一个进程中的线程共享进程的资源 进程是系统资源分配和调度的基本单位，线程是CPU调度的基本单位 每个线程都有程序运行的入口、顺序执行序列和出口，但线程不能独立的运行，必须依存在进程中，由进程提供多线程执行控制 进程和线程都可并发执行 线程和协程的比较 线程可以拥有多个协程，进程也可以独立拥有多个协程。（由于全局解释锁（GIL）的存在，python不能真正的进行多线程执行，但协程的存在使得python也能利用多核CPU） 线程调度由系统控制，协程调度则是由用户控制 进程和线程都是同步机制，协程是异步机制 协程保存上一次调用的状态，每次重新进入时，就相当于进入了上一次的调用状态（python典型：yield） 多进程和多线程 多任务：同一个计算机系统中允许两个及两个以上的进程处于运行状态 并行运行：CPU数 >= 线程数，所有线程则可同时运行 并发运行：CPU数 < 线程数，利用CPU时间片，将多个线程按照一定的顺序单个执行 并行运行的效率高于并行运行 进程间通信技术：消息传递、同步、共享内存、远程调用 IPC通信机制的优点：信息共享、加速、模块化、方便、私有权分离 IPC通信的方法：文件、信号量、管道、共享内存、socket套接字

MySQL 索引 全文索引 MySQL5.6 以后的版本中 MYISAM 和 InnoDB 引擎支持，仅可以在 char、varchar、text 列上创建全文索引。全文索引的出现主要是针对模糊查询， 全文索引是按照分词原理建立索引，MySQL的全文索引对中文不支持，需要安装插件提供对中文的支持 HASH 索引 MySQL 中只有 MEMORY 引擎显式支持 HASH 索引 hash 索引可以一次定位，不需要像树形索引进行逐层搜索 hash 索引仅能满足 “=”, “IN”, “!=” 查询，不能进行范围查询。主要是因为数据经过hash运算后存储位置不同，相邻的数据存储位置可能相差甚远 hash 索引无法避免排序运算 hash 索引不能利用部分索引建查询。使用多键建立 hash 索引，查询时无法利用其中部分键进行 hash 索引查询 hash 索引不能避免表扫描。当数据量大时，出现冲突，对于不同的 hash 冲突解决方法，需要进行表扫描来查找确切的数据 hash 索引当出现大量 hash 值相同时，索引速度不比树形索引高 BTREE 索引 MySQL 中默认的索引类型 主键索引：仅能在主键上建立的索引，一般是聚簇索引，数据的物理存储位置和聚簇索引的序号有关 唯一索引：必须唯一，但可以有空值 普遍索引：没有限制要求

Linux 目录结构和常用命令 目录结构 bin：二进制可执行文件目录（ls、cd等命令保存在此处） boot：存放用于启动Linux系统的核心文件 dev：设备文件目录 etc：存放系统的管理文件和配置文件 home：存放普通用户的家目录 lib：存放各种编程语言的共享库 lost + found：系统意外崩溃或机器意外关机产生的文件碎片 mnt：临时挂载文件系统时默认的挂载点 opt：存放额外安装的软件 proc：虚拟目录，系统内存中的进程以文件形式的体现 root：root用户的家目录 sbin：存放超级用户使用的二进制可执行文件 tmp：存放临时文件 usr：存放应用程序和文件的目录 var：存放经常变化的文件 usr/bin：安装软件的二进制可执行文件目录 usr/include：系统头文件（header files）的目录 usr/local：存放管理员自行安装的软件 usr/sbin：超级用户使用的二进制可执行文件的目录 usr/src：源代码存放目录 etc/passwd：保存系统中的用户 etc/group：保存系统中的用户组 dev/null：字符特殊文件，丢弃写入的一切数据，内容将会永远消失。无法读取 常用命令 系统信息 uname -r 显示内核版本 /proc/version 显示内核版本 /proc/cpuinfo CPU 信息 /proc/meminfo 内存信息 /proc/swap swap 被使用信息 /proc/net/dev 网络适配器及统计 /proc/mounts 已挂载的文件系统 date 显示系统时间 系统退出 shutdown -h 关闭系统 init 0 关闭系统 reboot 重启 shutdown -r 重启 logout 注销 文件和目录 cd 移动 pwd 显示路径 ls 显示目录中的文件 tree 显示文件和目录的树状结构 mkdir 创建文件夹 rm 删除文件 rmdir 删除文件夹（必须为空文件夹） mv 移动 cp 复制 ln 链接（-s 软连接） touch 创建文件 find 搜索 mount 挂载文件系统 umount 卸载文件系统 chmod 文件权限读写执行的修改 chown 改变文件的所有者或群组 磁盘空间 df 磁盘使用情况 du 文件和目录磁盘使用的空间的查看 用户和群组 groupadd 创建用户组 groupdel 删除用户组 groupmod 重命名用户组 useradd 创建用户 userdel 删除用户 usermod 修改用户属性 passwd 修改密码 打包和压缩文件 gzip 创建压缩文件 .

操作系统 - 死锁 定义 死锁是指多个进程因竞争资源而造成的一种相互等待的僵局，若无外力的作用，进程将无法继续进行 在多个程序系统中由于多个进程并发执行，改善了资源的利用率提高了系统的处理能力。但也会带来死锁问题 原因 系统资源的竞争：系统中拥有的不可剥夺资源不足以满足多个进程运行的需要，使得进程在运行过程中会因竞争资源而陷入僵局。只有对不可剥夺资源的竞争才可能产生死锁，对可剥夺资源的竞争是不会引起死锁 进程推进顺序非法：进程在运行中，申请和释放资源的顺序不当，也会导致死锁。信号量使用不当也会造成死锁。进程间彼此相互等待对方发来的消息，结果也会使得进程间无法继续向前推进 死锁产生的必要条件：产生死锁必须同时满足以下四条 互斥条件：进程要求的资源正在进行排他性控制。即在一段时间内某资源仅为一个进程所占有。此时若有其他进程请求该资源，则该请求只能进行等待 不剥夺条件：进程所获取的资源在未使用完毕之前，不能被其他进程所剥夺。即进程获取的资源只能由该进程进行释放 请求和保持条件：进程在请求新资源时，该资源被其他进程占有，则此请求堵塞，对已获得资源保持不变 循环等待条件：存在一种进程资源的循环等待链，链中每一个进程已获得的资源被链中的下一个进程所请求 处理策略 为了使系统不发生死锁，必须设法破坏产生死锁的四个必要条件之一，或者在死锁发生时能够检测出，并有能力将其恢复 预防死锁：设置某些条件，破坏产生死锁的四个必要条件，来防止产生死锁 避免死锁：在资源的动态分配过程中，使用某种方法防止系统进入不安全状态，从而避免死锁 死锁的检测与接触：无需采取任何措施，允许进程在运行过程中产生死锁。通过系统的检测机制及时的检测出死锁，然后采取某种方式接触死锁 预防死锁和避免死锁都属于事先预防策略，但预防死锁的限制条件比较严格，实现起来较为简单，但往往导致系统的效率低，资源利用率低；避免死锁的限制条件相对宽松，资源分配后需要通过算法来判断是否真正的进入不安全状态，实现起来较为复杂 死锁处理策略的比较 资源分配策略 各种可能模式 主要优点 主要缺点 死锁预防 保守，宁可闲置资源 一次请求所有的资源，资源剥夺，资源按序分配 适用于做突发式处理的进程，不必进行剥夺 效率低，进程初始化时间长；剥夺次数过多；不便灵活申请新资源 死锁避免 是预防和检测的折中办法，在运行时判断是否可能死锁 寻找可能的安全允许顺序 不必进行剥夺 必须知道将来的资源需求，进程不能长时间被堵塞 死锁检测 宽松，只要允许就分配资源 定期检测死锁是否已经发生 不延长进程初始化时间，允许对死锁进行现场处理 通过剥夺解除死锁，造成损失 死锁预防 破坏互斥条件：允许系统资源都能共享使用。显然是不现实的，有些资源无法同时访问。例：打印机 破坏不剥夺条件：当一个已保持了某些不剥夺资源的进程，请求新的资源而得不到满足时，它必须释放已经保持的所有资源，待以后需要时再重新申请。该策略实现比较复杂，释放已获得的资源可能造成前面完成的的工作失效，反复申请和释放资源也会增加系统的开销，降低系统的吞吐量 破坏请求和保持条件：采用预先静态资源分配方法，即进程在运行前申请完它所需的全部资源，在资源未满足之前不进行执行。一旦执行后资源一直归它所有，直至完成。该方式实现简单，但资源被严重浪费，其中有些资源仅在运行初期或运行结束时使用，甚至根本使用不到，而且还会导致“饥饿”现象，当某个资源被长期占用时，将导致等待该资源的进程迟迟不能运行 破坏循环和等待条件：采用顺序资源分配法，首先给系统中的资源编号，规定每个进程必须按编号进行递增的顺序请求资源，同类资源一次申请完。该种策略容易发生释放资源的编号和系统规定顺序不同的情况，造成资源的浪费；此外也会对用户编程造成麻烦 死锁避免 在资源动态分配过程中，防止系统进入不安全状态，以避免死锁。该策略施加的限制条件比较弱，可以获得较好的系统性能 银行家算法 该算法是将系统资源当作银行家管理的资金，进程向系统请求分配资源相当于用户向银行家贷款。操作系统按照银行家指定的规则为进程分配资源 当进程首次申请资源时，要测试该进程对资源的最大需求量 系统满足进程的最大需求量则按当前的申请分配资源，否则推迟分配 当进程执行过程中继续申请资源，则先测试进程已占用资源数与本次申请的资源数之和是否超过了该进程对资源的最大需求量。若超过则拒接分配，若没超过则在测试系统现存的资源是否满足该进程需要的最大资源数，若满足则按当前的申请量分配资源，否则推迟申请 死锁检测和解除 死锁定理：在资源分配图中，找出既不堵塞又不是孤点的进程，即资源分配图不可完全简化 死锁解除：一旦检测出死锁，就应该立即采取相应的措施解除死锁 资源剥夺法：挂起某些死锁进程，并抢占它的资源，将这些资源分配给其他的死锁进程。但应防止被挂起的进程长时间得不到资源，而处于资源匮乏状态 撤销进程法：强制撤销部分甚至全部的死锁进程。撤销的原则可以按照进程的优先级和撤销进程的代价的高低进行 进程回退法：让一个或多个进程回退到足以回避死锁的地步，进程回退时自愿释放资源而不是被剥夺。要求系统保持进程的历史信息，设置还原点

Django 一次请求响应的过程 概述 对于 python web 程序一般会分为两个部分：服务程序和应用程序 服务程序负责对 socket 服务器进行封装，在请求到来时对请求的数据进行整理 应用程序负责具体的逻辑处理。web 框架是为了方便应用程序开发而设计的 python 服务器网关接口（python web server gateway interface 缩写 WSGI）是 python 应用程序或者框架和 web 服务器之间的一种接口。WSGI 并没有官方实现，而是更像一种协议，只要遵照这些协议就可以在任何服务器上运行 Django 请求响应的过程 浏览器用户使用 url 发出一个请求 WEB 应用启动时会生成一个 WSGIHandler 实例 该实例会在第一次请求时调用 load_middleware 在执行 WSGIHandler 时会按照 settings.py 中的 MIDDLEWARE_CLASSES 顺序加载中间件 一个 middleware 包括请求响应的四个阶段 request、view、response、exception，对应方法：process_request、process_view、process_response、process_exception 构造 WSGIRequest 根据 HTTP 请求构造 WSGIRquest 请求 request 的 Middleware 中间件进行处理 对 request 请求进行预处理，此处可以限制爬虫、特定信息访问失效，返回 response 响应 URLConf 通过 url.py 文件将 request 请求的 URL 传递给相应的视图 该过程会创建 django.