操作系统1

一、操作系统的功能

（1）进程管理：①进程控制②进程同步（同步：信号量；互斥：互斥锁）③进程通信④调度（分为作业调度和进程调度）

（2）存储管理：①内存分配（静态分配和动态分配）②内存保护③地址映射④内存扩充（请求调入、置换功能）

（3）设备管理：①缓冲管理②设备分配③设备处理

（4）文件管理：①文件存储空间管理②目录管理③文件的读写管理和保护

二、I/O多路复用

原因：

​ 最基础的 TCP 的 Socket 编程，它是阻塞 I/O 模型，基本上只能一对一通信，那为了服务更多的客户端，我们需要改进网络 I/O 模型；传统的方式是使用多进程/线程模型，每来一个客户端连接，就分配一个进程/线程，然后后续的读写都在对应的进程/线程，这种方式当客户端的数量达到很大一个数量级时，进程/线程的调度、上下文切换以及它们占用的内存，都会成为瓶颈。

解决：

​ 为了解决上面这个问题，就出现了 I/O 多路复用技术，可以只在一个进程里处理多个文件的 I/O，Linux 下有三种提供 I/O 多路复用的 API，分别是：select、poll、epoll

（1）select 和 poll 并没有本质区别，它们内部都是使用「线性结构」来存储进程关注的 Socket 集合：首先需要把关注的 Socket 集合通过 select/poll 系统调用从用户态拷贝到内核态，然后由内核检测事件，当有网络事件产生时，内核需要遍历进程关注 Socket 集合，找到对应的 Socket，并设置其状态为可读/可写，然后把整个 Socket 集合从内核态拷贝到用户态，用户态还要继续遍历整个 Socket 集合找到可读/可写的 Socket，然后对其处理。

缺点： select 和 poll 的缺陷在于，当客户端越多，也就是 Socket 集合越大，Socket 集合的遍历和拷贝会带来很大的开销。

（2）epoll 通过两个方面解决了 select/poll 的问题：

①第一点，epoll 在内核里使用红黑树来跟踪进程所有待检测的文件描述字，把需要监控的 socket 通过 epoll_ctl() 函数加入内核中的红黑树里，红黑树是个高效的数据结构，增删查一般时间复杂度是 O(logn)，通过对这棵黑红树进行操作，这样就不需要像 select/poll 每次操作时都传入整个 socket 集合，只需要传入一个待检测的 socket，减少了内核和用户空间大量的数据拷贝和内存分配。

②第二点， epoll 使用事件驱动的机制，内核里维护了一个链表来记录就绪事件，当某个 socket 有事件发生时，通过回调函数ep_poll_callback()内核会将其加入到这个就绪事件列表中，当用户调用 epoll_wait() 函数时，只会返回有事件发生的文件描述符的个数，不需要像 select/poll 那样轮询扫描整个 socket 集合，大大提高了检测的效率。

（3）事件触发模式：边缘触发（*edge-triggered，ET*）和水平触发（*level-triggered，LT*）。

①使用边缘触发模式时，当被监控的 Socket 描述符上有可读事件发生时，服务器端只会从 epoll_wait 中苏醒一次，即使进程没有调用 read 函数从内核读取数据，也依然只苏醒一次，因此我们程序要保证一次性将内核缓冲区的数据读取完毕；

②使用水平触发模式时，当被监控的 Socket 上有可读事件发生时，服务器端不断地从 epoll_wait 中苏醒，直到内核缓冲区数据被 read 函数读完才结束，目的是告诉我们有数据需要读取。

注意： ①使用边缘触发模式时会循环从从文件描述符读写数据，如果文件描述符是阻塞的，没有数据可读写时，进程会阻塞在读写函数那里，程序没办法往下执行；所以边缘触发模式一般和非阻塞I/O一起使用，程序会一直执行I/O操作，直到系统调用返回错误。

②一般来说边缘触发的效率要比水平出发高，因为边缘触发可以减少epoll_wait的系统调用次数，系统调用也有一定的系统开销。

三、五种I/O模型

当“A”向"B" 发送一条消息，简单来说会经过如下流程：

第一步：应用A把消息发送到 TCP发送缓冲区。

第二步： TCP发送缓冲区再把消息发送出去，经过网络传递后，消息会发送到B服务器的TCP接收缓冲区。

**第三步：**B再从TCP接收缓冲区去读取属于自己的数据。

那么思考一个问题：上图中TCP缓冲区还没有接收到属于应用B该读取的消息时，那么此时应用B向TCP缓冲区发起读取申请；以及应用A在向TCP发送缓冲区发送数据时，如果TCP发送缓冲区已经满了，那么该怎么办呢？

（1）阻塞IO 和 非阻塞IO

​ **描述：**在应用调用recvfrom读取数据时，其系统调用直到数据包到达且被复制到应用缓冲区中或者发送错误时才返回，在此期间一直会等待，进程从调用到返回这段时间内都是被阻塞的称为阻塞IO；

​ **描述：**非阻塞IO是在应用调用recvfrom读取数据时，如果该缓冲区没有数据的话，就会直接返回一个EWOULDBLOCK错误，不会让应用一直等待中。在没有数据的时候会即刻返回错误标识，那也意味着如果应用要读取数据就需要不断的调用recvfrom请求，直到读取到它数据要的数据为止。

（2）I/O复用模型

​ 能不能提供一种方式，可以由一个线程监控多个网络请求（我们后面将称为fd文件描述符，linux系统把所有网络请求以一个fd来标识），这样就可以只需要一个或几个线程就可以完成数据状态询问的操作，当有数据准备就绪之后再分配对应的线程去读取数据，这么做就可以节省出大量的线程资源出来，这个就是IO复用模型的思路。

​ **描述：**进程通过将一个或多个fd传递给select（poll、epoll），阻塞在select操作上，select帮我们侦测多个fd是否准备就绪，当有fd准备就绪时，select返回数据可读状态，应用程序再调用recvfrom读取数据。

（3）信号驱动IO模型

​ 信号驱动IO不是用循环请求询问的方式去监控数据就绪状态，而是在调用sigaction时候建立一个SIGIO的信号联系，当内核数据准备好之后通过SIGIO信号通知询问线程 数据准备好，当线程收到可读状态的信号后，此时再向内核发起recvfrom读取数据的请求，因为信号驱动IO的模型下应用线程在发出信号监控后即可返回，不会阻塞，所以这样的方式下，一个应用线程也可以同时监控多个fd。

​ **描述：**首先开启套接口信号驱动IO功能，并通过系统调用sigaction执行一个信号处理函数，此时请求即刻返回，当数据准备就绪时，就生成对应进程的SIGIO信号，通过信号回调通知应用线程调用recvfrom来读取数据。

（4）异步IO模型

​ 之前不管是IO复用还是信号驱动，我们要读取一个数据总是要发起两阶段的请求，第一次发送select请求，询问数据状态是否准备好，第二次发送recevform请求读取数据。

​ 有人设计了一种方案，应用只需要向内核发送一个read 请求,告诉内核它要读取数据后即刻返回；内核收到请求后会建立一个信号联系，当数据准备就绪，内核会主动把数据从内核复制到用户空间，等所有操作都完成之后，内核会发起一个通知告诉应用，我们称这种一劳永逸的模式为异步IO模型。

​ 描述： 应用告知内核启动某个操作，并让内核在整个操作完成之后，通知应用，这种模型与信号驱动模型的主要区别在于，信号驱动IO只是由内核通知我们合适可以开始下一个IO操作，而异步IO模型是由内核通知我们操作什么时候完成。

**总结就是：**同步IO模型要求用户代码自行执行IO操作（将数据从内核缓冲区读入到用户缓冲区，或将数据从用户缓冲区写入内核缓冲区）；而异步IO机制则由内核执行IO操作（数据在内核缓冲区和用户缓冲区之间的移动由内核在后台完成）；可以这样认为：同步IO向应用程序通知的是IO就绪事件，而异步IO向应用程序通知的是IO完成事件。

四、进程与线程相关

1.僵死进程和孤儿进程

​ 正常情况下，子进程是通过父进程创建的，子进程再创建新的子进程；但是子进程的结束和父进程的运行是一个异步过程，即父进程永远无法预测子进程到底什么时候结束；当一个进程完成它的工作终止之后，它的父进程需要调用wait()或者waitpid()系统调用取得子进程的终止状态。

（1）僵尸进程：当进程退出，但是父进程并没有调用wait或者waitpid来获取子进程的状态信息时就会产生僵尸进程。

​ 危害：因为进程的退出状态必须要保持下去来告诉关心它的父进程，维护状态本身属于数据维护，保存在task_struct（PCB）中，因此PCB也一直要被维护，PCB是一个结构体要占用空间，所以会造成资源的浪费。

（2）孤儿进程：当一个父进程退出，而它的一个或多个子进程还在运行，那这些子进程将成为孤儿进程；孤儿进程将被init进程(进程号为1)所收养，并由init进程对它们完成状态收集工作。

2.进程和线程基础

（1）进程控制块（PCB）

​ 在操作系统中，是⽤进程控制块（process control block，PCB）数据结构来描述进程的；PCB 是进程存在的唯⼀标识，这意味着⼀个进程的存在，必然会有⼀个 PCB，如果进程消失 了，那么 PCB 也会随之消失。PCB主要包含以下：

​ **进程描述信息：**①进程标识符 ② ⽤户标识符

​ **进程控制和管理信息：**①进程当前状态 ②进程优先级

​ **资源分配清单：**有关内存地址空间或虚拟地址空间的信息，所打开⽂件的列表和所使⽤的 I/O 设备信息。

​ **CPU 相关信息：**CPU 中各个寄存器的值，当进程被切换时，CPU 的状态信息都会被保存在相应的 PCB 中，以便进程重新执⾏时，能从断点处继续执⾏。

​ PCB通常是通过链表的⽅式进⾏组织，把具有相同状态的进程链在⼀起，组成各种队列：就绪队列和阻塞队列；因为可能⾯临进程创建，销毁等调度导致进程状态发⽣变化，所以链表能 够更加灵活的插⼊和删除。

（2）CPU上下文

​ 操作系统在运行每个任务前，CPU 需要知道任务从哪⾥加载，⼜从哪里开始运行；所以操作系统需要事先帮 CPU 设置好 CPU 寄存器和程序计数器。

​ **CPU 寄存器：**是 CPU 内部⼀个容量⼩，但是速度极快的内存（缓存）。

​ **程序计数器：**是用来存储 CPU 正在执行的指令位置、或者即将执行的下⼀条指令位置。

​ CPU 上下文切换就是先把前⼀个任务的 CPU 上下⽂（CPU 寄存器和程序计数器）保存起来，然后加载新任务的上下文到这些寄存器和程序计数器，最后再跳转到程序计数器所指的新位置，运行新任务。

（3）进程上下文

​ 进程是由内核管理和调度的，所以进程的切换只能发生在内核态。所以，进程的上下文切换不仅包含了虚拟内存、栈、全局变量等用户空间的资源，还包括了内核堆栈、寄存器等内核空间的资源。

​ 通常，会把交换的信息保存在进程的 PCB，当要运行另外⼀个进程的时候，我们需要从这个进程的 PCB 取出上下文，然后恢复到 CPU 中，这使得这个进程可以继续执行。

（4）线程上下文

​ 线程上下文主要包括：所属线程的栈区、程序计数器、栈指针、函数运行使用的寄存器

​ 当两个线程不是属于同⼀个进程，则切换的过程就跟进程上下文切换⼀样； 当两个线程是属于同⼀个进程，因为虚拟内存是共享的，所以在切换时，虚拟内存这些资源就保持不动，只需要切换线程的私有数据、寄存器等不共享的数据。所以线程的上下文切换相比进程，开销要小很多。

​ 线程主要有三种实现方式：①用户线程：在⽤户空间实现的线程，不是由内核管理的线程，是由用户态的线程库来完成线程的管理；② 内核线程：在内核中实现的线程，是由内核管理的线程；③ 轻量级进程：在内核中来⽀持⽤户线程；

（5）调度原则

​ CPU 利⽤率：调度程序应确保 CPU 是始终匆忙的状态，这可提⾼ CPU 的利⽤率；

​ 系统吞吐量：吞吐量表示的是单位时间内 CPU 完成进程的数量，长作业的进程会占⽤较 ⻓的 CPU 资源，因此会降低吞吐量，相反，短作业的进程会提升系统吞吐量；

​ 周转时间：周转时间是进程运行和阻塞时间总和，⼀个进程的周转时间越小越好；

​ 等待时间：这个等待时间不是阻塞状态的时间，⽽是进程处于就绪队列的时间，等待的时间越⻓，用户越不满意；

​ 响应时间：⽤户提交请求到系统第⼀次产⽣响应所花费的时间，在交互式系统中，响应时间是衡量调度算法好坏的主要标准。

3.进程间通信

（1）管道（包括有名管道和无名管道）

（2）消息队列

（3）共享内存

（4）信号量

（5）信号

（6）Socket（套接字）

4.线程间通信

（1）信号：信号是进程间通信机制中唯⼀的异步通信机制，因为可以在任何时候发送信号给某⼀进程， ⼀旦有信号产⽣，我们就有下⾯这⼏种，⽤户进程对信号的处理⽅式。在线程通信中类似

（2）锁机制：互斥锁、读写锁、自旋锁

（3）条件变量：使用通知的方式解锁，与互斥锁配合使用

（4）信号量：一个整型计数器，主要用于实现进程/线程间的互斥与同步；通长用两种原子操作来实现（PV操作）

五、常见的几种锁

（1）互斥锁：

​ 互斥锁是一种「独占锁」，互斥锁加锁失败后，线程会释放 CPU ，给其他线程；这个操作是由操作系统内核实现的。当加锁失败时，内核会将线程置为「睡眠」状态，等到锁被释放后，内核会在合适的时机唤醒线程，当这个线程成功获取到锁后，于是就可以继续执行。会有两次线程上下文切换的成本：

（2）自旋锁：

​ 自旋锁加锁失败后，线程会忙等待，直到它拿到锁；所以，如果你能确定被锁住的代码执行时间很短，就不应该用互斥锁，而应该选用自旋锁，否则使用互斥锁。

​ 自旋锁是通过 CPU 提供的 CAS 函数（Compare And Swap），在「用户态」完成加锁和解锁操作，不会主动产生线程上下文切换，所以相比互斥锁来说，会快一些，开销也小一些。

​ 第一步，查看锁的状态，如果锁是空闲的，则执行第二步；第二步，将锁设置为当前线程持有；CAS 函数就把这两个步骤合并成一条硬件级指令，形成原子指令，这样就保证了这两个步骤是不可分割的，要么一次性执行完两个步骤，要么两个步骤都不执行。

（3）读写锁：

​ 读写锁适用于能明确区分读操作和写操作的场景。

​ 另外，根据实现的不同，读写锁可以分为「读优先锁」和「写优先锁」。

​ 公平读写锁比较简单的一种方式是：用队列把获取锁的线程排队，不管是写线程还是读线程都按照先进先出的原则加锁即可，这样读线程仍然可以并发，也不会出现「饥饿」的现象。

（4）悲观锁、乐观锁

​ 互斥锁、自旋锁、读写锁都属于悲观锁，悲观锁认为并发访问共享资源时，冲突概率可能非常高，所以在访问共享资源前，都需要先加锁。

​ 相反的，如果并发访问共享资源时，冲突概率非常低的话，就可以使用乐观锁，它的工作方式是，在访问共享资源时，不用先加锁，修改完共享资源后，再验证这段时间内有没有发生冲突，如果没有其他线程在修改资源，那么操作完成，如果发现有其他线程已经修改过这个资源，就放弃本次操作。