Python并发编程
多线程、多进程与多协程对比及实践指南
Python并发编程的三种主要方式：多线程（Thread）、多进程（Process）和多协程（Coroutine）。涵盖CPU/I/O密集型计算的定义、技术对比、选择策略、GIL（全局解释器锁）的解释与规避，以及多线程的实现方法。
1. CPU密集型计算与I/O密集型计算的定义
在并发编程中，任务类型决定了技术选择。以下是两类核心计算模式：
-
CPU密集型计算（CPU-bound）：
任务性能受限于CPU的处理能力。特点是CPU占用率高（例如80%以上），I/O操作快速完成，核心是大量计算。常见场景包括：- 数据压缩/解压缩
- 加密/解密算法正则表达式匹配
数学上，CPU密集型任务的执行时间可表示为： - 其中，计算量取决于算法复杂度。
-
I/O密集型计算（IO-bound）：
任务性能受限于I/O（输入/输出）操作，如磁盘读写、网络请求。特点是CPU占用率低，大部分时间在等待I/O完成。常见场景包括：- 文件处理程序
- 网络爬虫
- 数据库读写
执行时间模型为：是I/O等待时间，
是CPU处理时间。
关键区别：
- CPU密集型：优化重点在计算效率，如算法优化或多核并行。
- I/O密集型：优化重点在减少等待时间，如并发请求。
2. 多线程、多进程与多协程的对比
Python提供三种并发技术，各有优缺点。以下表格总结核心特性：
| 特性 | 多进程（Process） | 多线程（Thread） | 多协程（Coroutine） |
|---|---|---|---|
| 优点 | 利用多核CPU并行计算 | 轻量级，资源占用少 | 内存开销最小，启动数量最多 |
| 缺点 | 资源消耗大，启动数目有限 | 受GIL限制，不能多核并行；线程切换开销 | 库支持有限，代码复杂 |
| 适用场景 | CPU密集型计算 | I/O密集型计算，任务数适中 | I/O密集型计算，超多任务量 |
| 启动单位 | 进程间独立 | 线程共享进程资源 | 协程在单线程内切换 |
详细解释：
- 多进程：通过
multiprocessing模块实现，每个进程有独立内存和GIL，适合CPU密集型任务。但进程创建和上下文切换成本高，可启动数目受CPU核心数限制（例如4核CPU最多高效运行4进程）。 - 多线程：通过
threading模块实现，线程共享进程资源（如内存），适合I/O密集型任务。在I/O操作时，线程会释放GIL，允许CPU与I/O并行。但GIL限制多核CPU利用，且线程数过多时内存和切换开销增大。 - 多协程：通过
asyncio库实现，协程是用户级轻量线程，在单线程内通过事件循环切换，适合高并发I/O任务（如万级请求）。但需异步库支持（如aiohttp），代码实现较复杂。
3. 如何根据任务选择合适技术
选择技术需基于任务特点。以下是决策流程：
任务类型 → CPU密集型？ → 是 → 使用多进程（multiprocessing）
↓
→ I/O密集型？ → 是 → 判断：
│
├→ 需要超多任务量（如>1000）？ → 否 → 使用多线程（threading）
│ 是 →
├→ 有现成协程库支持？ → 否 → 使用多线程
│ 是 →
└→ 协程实现复杂度可接受？ → 否 → 使用多线程
是 → 使用多协程（asyncio）
示例应用：
- CPU密集型：图像处理任务 → 选择多进程。
- I/O密集型：Web爬虫（任务数100） → 选择多线程。
- I/O密集型：高并发API调用（任务数10000） → 选择多协程（如果库支持）。
4. 全局解释器锁（GIL）的解释与规避
GIL是Python解释器的同步机制，影响多线程性能。
-
GIL是什么：
GIL确保同一时刻只有一个线程执行Python字节码，防止多线程并发导致的数据竞争。例如，对象引用计数操作需原子性：
$ \text{obj.ref_num} = \text{obj.ref_num} - 1 $
若无GIL，多线程同时修改可能引发内存错误。 -
为什么存在GIL：
Python设计初期为简化内存管理（如引用计数）而引入GIL。现难以移除，因为涉及大量C扩展兼容性问题。GIL的好处是简化共享资源管理，但代价是限制多核并行。 -
如何规避GIL限制：
- 多线程用于I/O密集型任务：在I/O等待时，线程释放GIL，实现并发。例如，网络爬虫中，线程在等待响应时可切换。
- 使用多进程：每个进程有独立GIL，可并行利用多核CPU。适用于CPU密集型计算。
- 替代方案：使用JIT编译器（如PyPy）或C扩展（如Cython）绕过GIL。
性能影响：
在CPU密集型任务中，多线程可能比单线程更慢（由于GIL切换开销）。公式近似：
$$ \text{加速比} \approx \frac{1}{\text{GIL开销系数}} $$
对于I/O密集型，多线程可显著加速。
5. 多线程实现方法与爬虫加速示例
Python通过threading模块实现多线程。以下概括创建线程的方法和优势：
-
创建线程步骤：
- 导入
threading库。 - 定义任务函数（如爬取URL）。
- 创建线程对象：
thread = threading.Thread(target=函数名, args=(参数,))。 - 启动线程：
thread.start()。 - 等待线程结束：
thread.join()。
- 导入
-
多线程优势：
在I/O密集型任务中，多线程可大幅减少总执行时间。例如，在网络爬虫中：- 单线程：顺序爬取每个URL，总时间为各任务时间之和。
- 多线程：并发爬取，总时间近似于最慢任务时间（忽略创建开销）。
加速比可估算为：
$$ \text{加速比} \approx \frac{T_{\text{单线程}}}{T_{\text{I/O等待}} + \frac{T_{\text{处理}}}{N}} $$
其中$N$为线程数。
爬虫示例概括：
- 核心原理：模拟爬取多个网页（如分页链接），比较单线程与多线程耗时。
- 结果：多线程通常比单线程快数倍至数十倍（具体取决于网络延迟和任务数），验证了多线程在I/O密集型任务中的有效性。
- 注意：实际代码需处理线程同步和异常，但核心逻辑如上。
爬虫核心功能文件 ：
# 导入requests库：用于发送HTTP请求，获取网页内容（相当于模拟浏览器访问网页）
import requests
# 生成要爬取的URL列表：博客园首页的分页链接（从第1页到第50页）
# f-string格式化：把page变量代入，生成如"https://www.cnblogs.com/#p1"的链接
urls = [
f"https://www.cnblogs.com/#p{page}"
for page in range(1, 50+1) # range(1,51)生成1到50的整数（包含50）
]
# 定义爬虫核心函数：接收一个URL，爬取并打印该URL的网页文本长度
def craw(url):
# 发送GET请求获取网页内容：r是请求响应对象，包含网页的所有信息
r = requests.get(url)
# 打印当前URL + 该网页的文本长度（可以简单理解为网页的“字数”，验证是否爬取成功）
print(url, len(r.text))
# 测试：执行一次爬虫函数，爬取第1页的内容（验证函数是否能正常运行）
craw(urls[0]) 单线程 / 多线程对比执行文件 ：
# 导入threading库：用于创建和管理多线程（实现“同时干活”）
import threading
# 导入自定义的blog_spider模块：使用里面的urls列表和craw爬虫函数
import blog_spider
# 导入time库：用于计算程序运行耗时
import time
# 定义单线程执行函数：逐个爬取所有URL
def single_thread():
print("single_thread begin") # 打印开始提示，方便看执行流程
# 遍历所有要爬取的URL，逐个调用爬虫函数
for url in blog_spider.urls:
blog_spider.craw(url) # 单线程：爬完一个URL，再爬下一个
print("single_thread end") # 打印结束提示
# 定义多线程执行函数：同时启动多个线程爬取URL
def multi_thread():
print("multi_thread begin") # 打印开始提示
threads = [] # 定义空列表：用于存放所有创建的线程对象
# 第一步：创建线程对象（为每个URL创建一个线程）
for url in blog_spider.urls:
# 创建线程对象：
# target=blog_spider.craw：指定线程要执行的函数（即爬取函数）
# args=(url,)：指定传给craw函数的参数（必须是元组格式，单个参数也要加逗号）
thread = threading.Thread(target=blog_spider.craw, args=(url,))
threads.append(thread) # 把创建好的线程加入列表
# 第二步：启动所有线程（让所有线程“同时开始干活”）
for thread in threads:
thread.start() # 启动线程：线程启动后会自动执行target指定的craw函数
# 第三步：等待所有线程结束（主线程暂停，直到所有子线程都执行完）
for thread in threads:
thread.join() # 避免主线程先结束，导致子线程被强制终止
print("multi_thread end") # 打印结束提示
# 程序入口（只有直接运行该文件时，才会执行下面的代码）
if __name__ == "__main__":
# ========== 测试单线程耗时 ==========
start = time.time() # 记录单线程开始时间（time.time()返回当前时间戳，单位秒）
single_thread() # 执行单线程爬取
end = time.time() # 记录单线程结束时间
# 打印单线程总耗时：结束时间 - 开始时间
print("single thread cost:", end - start, "seconds")
# ========== 测试多线程耗时 ==========
start = time.time() # 记录多线程开始时间
multi_thread() # 执行多线程爬取
end = time.time() # 记录多线程结束时间
# 打印多线程总耗时
print("multi_thread cost:", end - start, "seconds") 代码解释
核心背景：这两段代码是干啥的？
简单说：写了一个 “自动爬取博客园 50 页内容” 的程序，对比 “一个人慢慢爬”（单线程）和 “50 个人同时爬”（多线程）的速度差异。
计算量速度
拆解关键概念
| 技术术语 | 解释 |
|---|---|
| 爬虫（craw） | 程序自动访问网页，把网页内容拿下来（代替人手动打开网页、看内容） |
| requests 库 | 爬虫的 “手脚”：帮程序发送 “访问网页” 的请求，拿回网页内容 |
| 单线程 | 一个工人干活：爬完第 1 页，再爬第 2 页，直到 50 页（串行执行，慢） |
| 多线程 | 50 个工人同时干活：每人负责爬 1 页，不用等别人（并行执行，快） |
| threading 库 | 管理 “工人” 的工具：创建 50 个工人、让他们同时开工、等所有人干完活 |
| time.time() | 计时工具：记录 “开始干活” 和 “干完活” 的时间，算总耗时 |
为什么多线程更快？
-
单线程：爬每个页面都要等 “网络请求→拿到内容→打印结果” 做完，才能换下一个，总耗时 = 50 个页面的耗时总和；
-
多线程：50 个页面的 “网络请求” 同时发，不用等前一个结束，总耗时≈最慢的那个页面的耗时（远小于单线程）。
注意点（避坑提醒）
-
threading.Thread的args参数必须是元组：哪怕只有 1 个参数，也要写成(url,)（少了逗号会报错）； -
thread.join()不能少：如果主线程不等子线程，可能主线程先结束，子线程还没爬完就被强制终止；运行结果预期
-
单线程会按顺序打印第 1~50 页的链接和文本长度，耗时较长（比如十几秒）；
-
多线程会乱序打印（因为 50 个线程同时执行），耗时很短（比如 1~2 秒）；
-
最终打印的耗时对比会明显看出：多线程 >> 单线程（快很多）。
总结
Python并发编程需根据任务类型选择技术：
- CPU密集型：优先用多进程（
multiprocessing）。 - I/O密集型：任务量适中时用多线程（
threading），超多任务时考虑多协程（asyncio）。
GIL限制了多线程的CPU并行，但通过多进程或I/O优化可规避。实践中，多线程在爬虫等I/O任务中能显著提升性能。建议结合具体场景测试优化。
更多推荐
16
0- 0
已为社区贡献1条内容
所有评论(0)