操作系统OS

进程和线程

• 进程：一个程序在一个数据集合上的一次运行过程，是对运行时程序的封装。进程是系统进行资源调度和分配的的基本单位， 实现了操作系统的并发；
• 线程：线程是进程的子任务， 是 CPU 调度和分派的基本单位， 用于保证程序的实时性， 实现进程内部的并发； 线程是操作系统可识别的最小执行和调度单位。

　　每个线程都独自占用一个虚拟处理器：独自的寄存器组， 指令计数器和处理器状态。每个线程完成不同的任务，但是共享同一地址空间，打开的文件队列和其他内核资源。

进程和线程的区别

• 线程依赖于进程而存在。一个线程只能属于一个进程， 而一个进程可以有多个线程， 但至少有一个线程。
• 进程在执行过程中拥有独立的内存单元， 而多个线程共享进程的内存。（资源分配给进程，同一进程的所有线程共享该进程的所有资源。同一进程中的多个线程共享代码段，数据段，堆存储 。 但是每个线程拥有自己的栈段， 用来存放所有局部变量和临时变量）

• 进程是资源分配的最小单位， 线程是 CPU 调度的最小单位；
• 进程间不会相互影响；线程一个线程挂掉将导致整个进程挂掉
• 进程在创建、 切换和销毁时开销比较大， 而线程比较小。

• 进程间通信比较复杂， 而同一进程的线程由于共享代码段和数据段， 所以通信比较容易。

进程间的通信

　　进程间通信主要包括管道、 系统 IPC（包括消息队列、 信号量、 信号、 共享内存等） 、 以及套接字 socket。

• 管道：管道主要包括无名管道和命名管道：管道可用于具有亲缘关系的父子进程间的通信， 有名管道除了具有管道所具有的功能外， 它还允许无亲缘关系进程间的通信。
• 消息队列：是消息的链接表， 存放在内核中。 一个消息队列由一个标识符（即队列 ID） 来标记。具有写权限得进程可以按照一定得规则向消息队列中添加新信息； 对消息队列有读权限得进程则可以从消息队列中读取信息；
• 信号量：信号量（semaphore） 是一个计数器， 可以用来控制多个进程对共享资源的访问。信号量用于实现进程间的互斥与同步， 若要在进程间传递数据需要结合共享内存。
• 信号：信号是一种比较复杂的通信方式， 用于通知接收进程某个事件已经发生。
• 共享内存（Shared Memory)：它使得多个进程可以访问同一块内存空间， 不同进程可以及时看到对方进程中对共享内存中数据得更新。 这种方式需要依靠某种同步操作， 如互斥锁和信号量等。
• 套接字 SOCKET：socket 也是一种进程间通信机制， 与其他通信机制不同的是， 它可用于不同主机之间的进程通信。

线程间的通信方式

• 临界区：通过多线程的串行化来访问公共资源或一段代码， 速度快， 适合控制数据访问；

1. 互斥量 Synchronized/Lock：采用互斥对象机制， 只有拥有互斥对象的线程才有访问公共资源的权限。 因为互斥对象只有一个， 所以可以保证公共资源不会被多个线程同时访问。

• 信号量 Semphare：为控制具有有限数量的用户资源而设计的， 它允许多个线程在同一时刻去访问同一个资源， 但一般需要限制同一时刻访问此资源的最大线程数目。

• 事件(信号)， Wait/Notify：通过通知操作的方式来保持多线程同步， 还可以方便的实现多线程优先级的比较操作

• 全局变量

锁机制

• 互斥锁： mutex， 用于保证在任何时刻， 都只能有一个线程访问该对象。 当获取锁操作失败时， 线程会进入睡眠， 等待锁释放时被唤醒
• 读写锁： rwlock， 分为读锁和写锁。 处于读操作时， 可以允许多个线程同时获得读操作。 但是同一时刻只能有一个线程可以获得写锁。 其它获取写锁失败的线程都会进入睡眠状态， 直到写锁释放时被唤醒。 注意： 写锁会阻塞其它读写锁。 当有一个线程获得写锁在写时， 读锁也不能被其它线程获取； 写者优先于读者（一旦有写者， 则后续读者必须等待， 唤醒时优先考虑写者） 。适用于读取数据的频率远远大于写数据的频率的场合。
• 自旋锁： spinlock， 在任何时刻同样只能有一个线程访问对象。 但是当获取锁操作失败时，不会进入睡眠， 而是会在原地自旋， 直到锁被释放。 这样节省了线程从睡眠状态到被唤醒期间的消耗， 在加锁时间短暂的环境下会极大的提高效率。 但如果加锁时间过长， 则会非常浪费 CPU资源。
• RCU： 即 read-copy-update， 在修改数据时， 首先需要读取数据， 然后生成一个副本， 对副本进行修改。 修改完成后， 再将老数据 update 成新的数据。 使用 RCU 时， 读者几乎不需要同步开销， 既不需要获得锁， 也不使用原子指令， 不会导致锁竞争， 因此就不用考虑死锁问题了。 而对于写者的同步开销较大， 它需要复制被修改的数据， 还必须使用锁机制同步并行其它写者的修改操作。 在有大量读操作， 少量写操作的情况下效率非常高。

堆和栈

• 栈由操作系统自动分配释放 ，用于存放函数的参数值、局部变量等。
• 堆由开发人员分配和释放， 若开发人员不释放，程序结束时由 OS 回收，分配方式类似于链表

堆与栈实际上是操作系统对进程占用的内存空间的两种管理方式，主要有如下几种区别：
（1）管理方式不同。栈由操作系统自动分配释放，无需我们手动控制；堆的申请和释放工作由程序员控制，容易产生内存泄漏；

（2）空间大小不同。每个进程拥有的栈大小要远远小于堆大小。理论上，进程可申请的堆大小为虚拟内存大小，进程栈的大小 64bits 的 Windows 默认 1MB，64bits 的 Linux 默认 10MB；

（3）生长方向不同。堆的生长方向向上，内存地址由低到高；栈的生长方向向下，内存地址由高到低。

（4）分配方式不同。堆都是动态分配的，没有静态分配的堆。栈有 2 种分配方式：静态分配和动态分配。静态分配是由操作系统完成的，比如局部变量的分配。动态分配由alloca()函数分配，但是栈的动态分配和堆是不同的，它的动态分配是由操作系统进行释放，无需我们手工实现。

（5）分配效率不同。栈由操作系统自动分配，会在硬件层级对栈提供支持：分配专门的寄存器存放栈的地址，压栈出栈都有专门的指令执行，这就决定了栈的效率比较高。堆则是由C/C++提供的库函数或运算符来完成申请与管理，实现机制较为复杂，频繁的内存申请容易产生内存碎片。显然，堆的效率比栈要低得多。

（6）存放内容不同。栈存放的内容，函数返回地址、相关参数、局部变量和寄存器内容等。当主函数调用另外一个函数的时候，要对当前函数执行断点进行保存，需要使用栈来实现，首先入栈的是主函数下一条语句的地址，即扩展指针寄存器的内容（EIP），然后是当前栈帧的底部地址，即扩展基址指针寄存器内容（EBP），再然后是被调函数的实参等，一般情况下是按照从右向左的顺序入栈，之后是被调函数的局部变量，注意静态变量是存放在数据段或者BSS段，是不入栈的。出栈的顺序正好相反，最终栈顶指向主函数下一条语句的地址，主程序又从该地址开始执行。堆，一般情况堆顶使用一个字节的空间来存放堆的大小，而堆中具体存放内容是由程序员来填充的。

从以上可以看到，堆和栈相比，由于大量malloc()/free()或new/delete的使用，容易造成大量的内存碎片，并且可能引发用户态和核心态的切换，效率较低。栈相比于堆，在程序中应用较为广泛，最常见的是函数的调用过程由栈来实现，函数返回地址、EBP、实参和局部变量都采用栈的方式存放。虽然栈有众多的好处，但是由于和堆相比不是那么灵活，有时候分配大量的内存空间，主要还是用堆。

无论是堆还是栈，在内存使用时都要防止非法越界，越界导致的非法内存访问可能会摧毁程序的堆、栈数据，轻则导致程序运行处于不确定状态，获取不到预期结果，重则导致程序异常崩溃，这些都是我们编程时与内存打交道时应该注意的问题。

I/O多路复用

• 什么是I/O多路复用？
  单线程或单进程同时监测若干个文件描述符是否可以执行IO操作的能力
• 解决什么问题？
  

  应用程序通常需要处理来自多条事件流中的事件，比如我现在用的电脑，需要同时处理键盘鼠标的输入、中断信号等等事件，再比如web服务器如nginx，需要同时处理来来自N个客户端的事件。

  逻辑控制流在时间上的重叠叫做 并发

  而CPU单核在同一时刻只能做一件事情，一种解决办法是对CPU进行时分复用(多个事件流将CPU切割成多个时间片，不同事件流的时间片交替进行)。在计算机系统中，我们用线程或者进程来表示一条执行流，通过不同的线程或进程在操作系统内部的调度，来做到对CPU处理的时分复用。这样多个事件流就可以并发进行，不需要一个等待另一个太久，在用户看起来他们似乎就是并行在做一样。

  但凡事都是有成本的。线程/进程也一样，有这么几个方面：

  1. 线程/进程创建成本
  2. CPU切换不同线程/进程成本 Context Switch
  3. 多线程的资源竞争

  有没有一种可以在单线程/进程中处理多个事件流的方法呢？一种答案就是IO多路复用。

  因此IO多路复用解决的本质问题是在用更少的资源完成更多的事。

• I/O模型
  

  目前Linux系统中提供了5种IO处理模型

  1. 阻塞IO
  2. 非阻塞IO
  3. IO多路复用
  4. 信号驱动IO
  5. 异步IO

  阻塞IO

  这是最常用的简单的IO模型。阻塞IO意味着当我们发起一次IO操作后一直等待成功或失败之后才返回，在这期间程序不能做其它的事情。阻塞IO操作只能对单个文件描述符进行操作。

  非阻塞IO

  我们在发起IO时，通过对文件描述符设置O_NONBLOCK flag来指定该文件描述符的IO操作为非阻塞。非阻塞IO通常发生在一个for循环当中，因为每次进行IO操作时要么IO操作成功，要么当IO操作会阻塞时返回错误EWOULDBLOCK/EAGAIN，然后再根据需要进行下一次的for循环操作，这种类似轮询的方式会浪费很多不必要的CPU资源，是一种糟糕的设计。和阻塞IO一样，非阻塞IO也是通过调用read或writewrite来进行操作的，也只能对单个描述符进行操作。

  IO多路复用

  IO多路复用在Linux下包括了三种，select、poll、epoll，抽象来看，他们功能是类似的，但具体细节各有不同：首先都会对一组文件描述符进行相关事件的注册，然后阻塞等待某些事件的发生或等待超时。

  信号驱动IO

  信号驱动IO是利用信号机制，让内核告知应用程序文件描述符的相关事件。这里有一个信号驱动IO相关的例子。

  但信号驱动IO在网络编程的时候通常很少用到，因为在网络环境中，和socket相关的读写事件太多了，比如下面的事件都会导致SIGIO信号的产生：

  1. TCP连接建立
  2. 一方断开TCP连接请求
  3. 断开TCP连接请求完成
  4. TCP连接半关闭
  5. 数据到达TCP socket
  6. 数据已经发送出去(如：写buffer有空余空间)

  上面所有的这些都会产生SIGIO信号，但我们没办法在SIGIO对应的信号处理函数中区分上述不同的事件，SIGIO只应该在IO事件单一情况下使用，比如说用来监听端口的socket，因为只有客户端发起新连接的时候才会产生SIGIO信号。

  异步IO

  异步IO和信号驱动IO差不多，但它比信号驱动IO可以多做一步：相比信号驱动IO需要在程序中完成数据从用户态到内核态(或反方向)的拷贝，异步IO可以把拷贝这一步也帮我们完成之后才通知应用程序。我们使用 aio_read 来读，aio_write 写。

  同步IO vs 异步IO 1. 同步IO指的是程序会一直阻塞到IO操作如read、write完成 2. 异步IO指的是IO操作不会阻塞当前程序的继续执行
  所以根据这个定义，上面阻塞IO当然算是同步的IO，非阻塞IO也是同步IO，因为当文件操作符可用时我们还是需要阻塞的读或写，同理IO多路复用和信号驱动IO也是同步IO，只有异步IO是完全完成了数据的拷贝之后才通知程序进行处理，没有阻塞的数据读写过程。

• IO多路复用

  select/poll

  select的实现多路复用器的方式就是 将建立连接Socket 都放到一个 文件描述符集合，然后调用 select 函数将文件描述集合拷贝到内核中，然后内核通过遍历这个集合，当检查到有事件产生后，将此 Socket 标记为可读或可写， 接着再把整个文件描述符集合拷贝回用户态里，然后用户态还需要再通过遍历的方法找到可读或可写的 Socket，然后再对其处理。

  对于 select 这种方式，需要进行 2 次遍历文件描述符集合，一次是在内核态里，一个次是在用户态里 ，而且还会发生 2 次拷贝文件描述符集合，先从用户空间传入内核空间，由内核修改后，再传出到用户空间中。 poll实现多路复用器的方式跟select一样，只是select有长度限制， 使用固定长度的 BitsMap，而poll没有，采用动态数组保存，突破了 select 的文件描述符个数限制，当然还会受到系统文件描述符限制。

  poll 和 select 并没有太大的本质区别，都是使用「线性结构」存储进程关注的 Socket 集合，因此都需要遍历文件描述符集合来找到可读或可写的 Socket，时间复杂度为 O(n)，而且也需要在用户态与内核态之间拷贝文件描述符集合，这种方式随着并发数上来，性能的损耗会呈指数级增长。

 

epoll

epoll 通过两个方面，很好解决了 select/poll 的问题。

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

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

             

epoll 的方式即使监听的 Socket 数量越多的时候，效率不会大幅度降低，能够同时监听的 Socket 的数目也非常的多了，上限就为系统定义的进程打开的最大文件描述符个数。因而，epoll 被称为解决 C10K 问题的利器。

epoll 支持两种事件触发模式 边缘触发（edge-triggered，ET） 水平触发（level-triggered，LT）

 

1. 使用边缘触发模式时，当被监控的 Socket 描述符上有可读事件发生时，服务器端只会从 epoll_wait 中苏醒一次，即使进程没有调用 read 函数从内核读取数据，也依然只苏醒一次，因此我们程序要保证一次性将内核缓冲区的数据读取完；
2. 使用水平触发模式时，当被监控的 Socket 上有可读事件发生时，服务器端不断地从 epoll_wait 中苏醒，直到内核缓冲区数据被 read 函数读完才结束，目的是告诉我们有数据需要读取；

 

举个例子，你的快递被放到了一个快递箱里，如果快递箱只会通过短信通知你一次，即使你一直没有去取，它也不会再发送第二条短信提醒你，这个方式就是边缘触发；如果快递箱发现你的快递没有被取出，它就会不停地发短信通知你，直到你取出了快递，它才消停，这个就是水平触发的方式。

这就是两者的区别，水平触发的意思是只要满足事件的条件，比如内核中有数据需要读，就一直不断地把这个事件传递给用户；而边缘触发的意思是只有第一次满足条件的时候才触发，之后就不会再传递同样的事件了。

如果使用水平触发模式，当内核通知文件描述符可读写时，接下来还可以继续去检测它的状态，看它是否依然可读或可写。所以在收到通知后，没必要一次执行尽可能多的读写操作。

如果使用边缘触发模式，I/O 事件发生时只会通知一次，而且我们不知道到底能读写多少数据，所以在收到通知后应尽可能地读写数据，以免错失读写的机会。因此，我们会循环从文件描述符读写数据，那么如果文件描述符是阻塞的，没有数据可读写时，进程会阻塞在读写函数那里，程序就没办法继续往下执行。所以，边缘触发模式一般和非阻塞 I/O 搭配使用，程序会一直执行 I/O 操作，直到系统调用（如 read 和 write）返回错误，错误类型为 EAGAIN 或 EWOULDBLOCK。

一般来说，边缘触发的效率比水平触发的效率要高，因为边缘触发可以减少 epoll_wait 的系统调用次数，系统调用也是有一定的开销的的，毕竟也存在上下文的切换。

select/poll 只有水平触发模式，epoll 默认的触发模式是水平触发，但是可以根据应用场景设置为边缘触发模式。

简单点理解，就是多路复用 API 返回的事件并不一定可读写的，如果使用阻塞 I/O， 那么在调用 read/write 时则会发生程序阻塞，因此最好搭配非阻塞 I/O，以便应对极少数的特殊情况。

总结

最基础的 TCP 的 Socket 编程，它是阻塞 I/O 模型，基本上只能一对一通信，那为了服务更多的客户端，我们需要改进网络 I/O 模型。

比较传统的方式是使用多进程/线程模型，每来一个客户端连接，就分配一个进程/线程，然后后续的读写都在对应的进程/线程，这种方式处理 100 个客户端没问题，但是当客户端增大到 10000 个时，10000 个进程/线程的调度、上下文切换以及它们占用的内存，都会成为瓶颈。

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

select 和 poll 并没有本质区别，它们内部都是使用「线性结构」来存储进程关注的 Socket 集合。

在使用的时候，首先需要把关注的 Socket 集合通过 select/poll 系统调用从用户态拷贝到内核态，然后由内核检测事件，当有网络事件产生时，内核需要遍历进程关注 Socket 集合，找到对应的 Socket，并设置其状态为可读/可写，然后把整个 Socket 集合从内核态拷贝到用户态，用户态还要继续遍历整个 Socket 集合找到可读/可写的 Socket，然后对其处理。

很明显发现，select 和 poll 的缺陷在于，当客户端越多，也就是 Socket 集合越大，Socket 集合的遍历和拷贝会带来很大的开销，因此也很难应对 C10K。

epoll 是解决 C10K 问题的利器，通过两个方面解决了 select/poll 的问题。

epoll 在内核里使用「红黑树」来关注进程所有待检测的 Socket，红黑树是个高效的数据结构，增删查一般时间复杂度是 O(logn)，通过对这棵黑红树的管理，不需要像 select/poll 在每次操作时都传入整个 Socket 集合，减少了内核和用户空间大量的数据拷贝和内存分配。 epoll 使用事件驱动的机制，内核里维护了一个「链表」来记录就绪事件，只将有事件发生的 Socket 集合传递给应用程序，不需要像 select/poll 那样轮询扫描整个集合（包含有和无事件的 Socket ），大大提高了检测的效率。 而且，epoll 支持边缘触发和水平触发的方式，而 select/poll 只支持水平触发，一般而言，边缘触发的方式会比水平触发的效率高。

 

进程调度算法：

• 先来先服务调度算法（FCFS）：FCFS调度算法利于长作业，不利于短作业。
• 短作业优先调度算法（SJF）：有效降低作业的平均等待时间和提高系统的吞吐量。
• 时间片轮转调度算法（RR）：简单易行、平均响应时间短。此算法不利于处理紧急作业

注：时间片的大小可调整，如果时间片大到让一个进程足以完成其全部工作，这种算法就退化为FCFS调度算法；若时间片设置得很小，那么处理机在进程之间的进程上下文切换工作过于频繁，使得真正用于运行用户程序的时间减少。时间片可以静态设置好，也可根据系统当前负载状况和运行情况动态调整，时间片大小的动态调整需要考虑就绪态进程个数、进程上下文切换开销、系统吞吐量、系统响应时间等多方面因素。

• 高响应比优先调度算法（HRRF）：Rp=（等待时间+预计执行时间）/执行时间=响应时间/执行时间，Rp较大的进程执行。既考虑进程等待时间，又考虑进程的执行时间。 但HRRF调度算法需要每次计算各各个进程的响应比Rp，这会带来较大的时间开销（特别是在就绪进程个数多的情况下）。
• 多级反馈队列调度算法（MLFQ）设置多个就绪队列，并为各个队列赋予不同的优先级。第一个队列的优先级最高，第二队次之，其余队列优先级依次降低。
• 最高优先级优先调度算法：进程的优先级用于表示进程的重要性及运行的优先性。一个进程的优先级可分为两种：静态优先级和动态优先级。
• 静态优先级是在创建进程时确定的。一旦确定后，在整个进程运行期间不再改变。静态优先级一般由用户依据包括进程的类型、进程所使用的资源、进程的估计运行时间等因素来设置。一般而言，若进程需要的资源越多、估计运行的时间越长，则进程的优先级越低；反之，对于I/O bounded的进程可以把优先级设置得高。
• 动态优先级是指在进程运行过程中，根据进程执行情况的变化来调整优先级。动态优先级一般根据进程占有CPU时间的长短、进程等待CPU时间的长短等因素确定。占有处理机的时间越长，则优先级越低，等待时间越长，优先级越高。那么进程调度器将根据静态优先级和动态优先级的总和现在优先级最高的就绪进程执行。