为你揭秘 Python 中的进程线程协程同步异步回调

Posted 2020-10-02

进程和线程究竟是什么东西？传统网络服务模型是如何工作的？协程和线程的关系和区别有哪些？IO 过程在什么时间发生？

一、我们来介绍一下上下文切换技术

关于一些术语。当我们说“上下文”的时候，指的是程序在执行中的一个状态。通常我们会调用栈来表示这个状态。栈——记载了每个调用层级执行了哪里和执行时的环境情况等所有有关的信息。

当我们说“上下文切换”的时候，表达的是一种从一个上下文切换到另一个上下文执行的技术。而“调度”指的是决定哪个上下文可以获得接下来的 CPU 时间的方法。

进程

进程是一种古老而典型的上下文系统，每个进程有独立的地址空间，资源句柄，他们互相之间不发生干扰。每个进程在内核中都会有一个数据结构进行描述，我们称其为进程描述符。这些描述符包含了系统管理进程所需的信息，并且放在一个叫做任务队列的队列里面。

很显然，当新建进程时，我们需要分配新的进程描述符，并且分配新的地址空间(和父地址空间的映射保持一致，但是两者同时进入 COW 状态)。这些过程需要一定的开销。

进程状态

忽略去 linux 内核复杂的状态转移表，我们实际上可以把进程状态归结为三个最主要的状态：就绪态，运行态，睡眠态。这就是任何一本系统书上都有的三态转换图。

就绪和执行可以互相转换，基本这就是调度的过程。而当执行态程序需要等待某些条件(最典型就是IO)时，就会陷入睡眠态。而条件达成后，一般会自动进入就绪。

阻塞

当进程需要在某个文件句柄上做 IO，这个 fd 又没有数据给他的时候，就会发生阻塞。具体来说，就是

记录XX进程阻塞在了XX fd上，然后将进程标记为睡眠态，并调度出去。当 fd 上有数据时(例如对端发送的数据到达)，就会唤醒阻塞在fd上的进程。进程会随后进入就绪队列，等待合适的时间被调度。

阻塞后的唤醒也是一个很有意思的话题。当多个上下文阻塞在一个 fd 上(虽然不多见，但是后面可以看到一个例子)，而且 fd 就绪时，应该唤醒多少个上下文呢？传统上应当唤醒所有上下文，因为如果仅唤醒一个，而这个上下文又不能消费所有数据时，就会使得其他上下文处于无谓的死锁中。

但是有个著名的例子——accept，也是使用读就绪来表示收到的。如果试图用多个线程来 accept 会生什么？当有新连接时，所有上下文都会就绪，但是只有第一个可以实际获得 fd，其他的被调度后又立刻阻塞。这就是惊群问题 thundering herd problem。

现代linux内核已经解决了这个问题，方法惊人的简单——accept方法加锁。

(inet_connection_sock.c:inet_csk_wait_for_connect)

线程

线程是一种轻量进程，实际上在 linux 内核中，两者几乎没有差别，除了一点——线程并不产生新的地址空间和资源描述符表，而是复用父进程的。但是无论如何，线程的调度和进程一样，必须陷入内核态。

二、关于传统网络服务模型

进程模型

为每个客户分配一个进程。优点是业务隔离，在一个进程中出现的错误不至于影响整个系统，甚至其他进程。Oracle 传统上就是进程模型。缺点是进程的分配和释放有非常高的成本。因此 Oracle 需要连接池来保持连接减少新建和释放，同时尽量复用连接而不是随意的新建连接。

线程模型

为每客户分配一个线程。优点是更轻量，建立和释放速度更快，而且多个上下文间的通讯速度非常快。缺点是一个线程出现问题容易将整个系统搞崩溃。

我们举一个例子

py_http_fork_thread.py

在这个例子中，线程模式和进程模式可以轻易的互换。

我们来分析它是如何工作的：

1. 父进程监听服务端口

2. 在有新连接建立的时候，父进程执行 fork，产生一个子进程副本

3. 如果子进程需要的话，可以 exec (例如 CGI )

4. 父进程执行(理论上应当先执行子进程，因为exec执行的快可以避免 COW )到 accept 后，发生阻塞

5. 上下文调度，内核调度器选择下一个上下文，如无意外，应当就是刚刚派生的子进程

6. 子进程进程进入读取处理状态，阻塞在read调用上，所有上下文均进入睡眠态

7. 随着 SYN 或者数据报文到来，CPU 会唤醒对应fd上阻塞的上下文( wait_queue )，切换到就绪态，并加入调度队列

8. 上下文继续执行到下一个阻塞调用，或者因为时间片耗尽被挂起

评价

• 同步模型，编写自然，每个上下文可以当作其他上下文不存在一样的操作，每次读取数据可以当作

• 必然能读取到。

• 进程模型自然的隔离了连接。即使程序复杂且易崩溃，也只影响一个连接而不是在整个系统。

• 生成和释放开销很大(效率测试的进程 fork 和线程模式开销测试)，需要考虑复用。

• 进程模式的多客户通讯比较麻烦，尤其在共享大量数据的时候。

性能

thread 模式，虚拟机：

1: 909.27 2: 3778.38 3: 4815.37 4: 5000.04 10: 4998.16 50: 4881.93 100: 4603.24 200:3445.12 500: 1778.26 (出现错误)

fork 模式，虚拟机：

1: 384.14 2: 435.67 3: 435.17 4: 437.54 10: 383.11 50: 364.03 100: 320.51 (出现错误)

thread 模式，物理机：

1: 6942.78 2: 6891.23 3: 6584.38 4: 6517.23 10: 6178.50 50: 4926.91 100: 2377.77

注意：在 python 中，虽然有GIL，但是一个线程陷入到网络 IO 的时候，GIL 是解锁的。因此从调用开

始到调用结束，减去 CPU 切换到其他上下文的时间，是可以多线程的。现象是，在此种状况下可以观测

到短暂的 python CPU 用量超过100%。

如果执行多个上下文，可以充分利用这段时间。所观测到的结果就是，只能单核的 python，在小范围内，其随着并发数上升，性能居然会跟着上升。如果将这个过程转移到一台物理机上执行，那么基本不

能得出这样的结论。这主要是因为虚拟机上内核陷入的开销更高。

三、我们来说一些 C10K 问题

当同时连接数在10K左右时，传统模型就不再适用。实际上在效率测试报告的线程切换开销一节可以看到，超过1K后性能就差的一塌糊涂了。

进程模型的问题：

在 C10K 的时候，启动和关闭这么多进程是不可接受的开销。事实上单纯的进程 fork 模型在 C1K 时就

应当抛弃了。

Apache 的 prefork 模型，是使用预先分配(pre)的进程池。这些进程是被复用的。但即便是复用，本文所描述的很多问题仍不可避免。

线程模式的问题

从任何测试都可以表明，线程模式比进程模式更耐久一些，性能更好。但是在面对 C10K 还是力不从心

的。问题是，线程模式的问题出在哪里呢？

关于内存问题

有些人可能认为线程模型的失败首先在于内存。如果你这么认为，一定是因为你查阅了非常老的资料，并且没仔细思考过。你可能看到某些资料说，一个线程栈会消耗8M内存( linux 默认值，ulimit 可以看

到)，512个线程栈就会消耗4G内存，而10K个线程就是80G。所以首先要考虑调整栈深度，并考虑爆栈问题。听起来很有道理，问题是——linux的栈是通过缺页来分配内存的(How does stack allocation work in Linux?)，不是所有栈地址空间都分配了内存。因此，8M是最大消耗，实际的内存消耗只会略大于实际需要的内存(内部损耗，每个在4k以内)。但是内存一旦被分配，就很难回收(除非线程结束)，这是线程模式的缺陷。

这个问题提出的前提是，32位下地址空间有限。虽然10K个线程不一定会耗尽内存，但是512个线程一定

会耗尽地址空间。然而这个问题对于目前已经成为主流的64位系统来说根本不存在。

内核陷入开销的问题

所谓内核陷入开销，就是指 CPU 从非特权转向特权，并且做输入检查的一些开销。这些开销在不同

的系统上差异很大。

线程模型主要通过陷入切换上下文，因此陷入开销大听起来有点道理。实际上，这也是不成立的。线程

在什么时候发生陷入切换？正常情况下，应当是 IO 阻塞的时候。同样的 IO 量，难道其他模型就不需要陷入了么？只是非阻塞模型有很大可能直接返回，并不发生上下文切换而已。效率测试报告的基础调用开销一节，证实了当代操作系统上内核陷入开销是非常惊人的小的(10个时钟周期这个量级)。线程模型的问题在于切换成本高。

熟悉linux内核的应该知道，近代linux调度器经过几个阶段的发展。

• linux2.4的调度器

• O(1)调度器

• CFS

实际上直到 O(1) 调度器的调度复杂度才和队列长度无关。在此之前，过多的线程会使得开销随着线

程数增长(不保证线性)。

O(1) 调度器看起来似乎是完全不随着线程的影响。但是这个调度器有显著的缺点——难于理解和维护，

并且在一些情况下会导致交互式程序响应缓慢。

CFS 使用红黑树管理就绪队列。每次调度，上下文状态转换，都会查询或者变更红黑树。红黑树的开销

大约是 O(logm)，其中m大约为活跃上下文数(准确的说是同优先级上下文数)，大约和活跃的客户数相当。

因此，每当线程试图读写网络，并遇到阻塞时，都会发生 O(logm) 级别的开销。而且每次收到报文，唤

醒阻塞在 fd 上的上下文时，同样要付出 O(logm) 级别的开销。

O(logm) 的开销看似并不大，但是却是一个无法接受的开销。因为 IO 阻塞是一个经常发生的事情。每

次 IO 阻塞，都会发生开销。而且决定活跃线程数的是用户，这不是我们可控制的。更糟糕的是，当性能下降，响应速度下降时。同样的用户数下，活跃上下文会上升(因为响应变慢了)。这会进一步拉低性能。

问题的关键在于，http 服务并不需要对每个用户完全公平，偶尔某个用户的响应时间大大的延长了是可以接受的。在这种情况下，使用红黑树去组织待处理 fd 列表（其实是上下文列表），并且反复计算

和调 度，是无谓的开销。

本文出自 “Python & Golang 学习” 博客，转载请与作者联系！