3、CPU密集型任务瓶颈：GIL对CPU密集型任务的影响、多进程 vs 多线程的选择、使用concurrent.futures模块

聊到CPU密集型任务，很多Python开发者第一反应就是「慢」。说实话，这锅不全在Python语言本身，更多是GIL这个老伙计在捣乱。我在几年前接手过一个实时数据清洗服务，单核跑满，其他核心在围观，那叫一个憋屈。今天我们就来彻底掰扯清楚这个问题。

3.1 GIL到底是什么？它怎么卡住CPU密集型任务的？

GIL，全称Global Interpreter Lock，全局解释器锁。说白了，它就是CPython解释器里的一把大锁。这把锁规定：同一时刻，只有一个线程能执行Python字节码。

你想想看，如果你开了8个线程去算圆周率，结果它们排队用CPU，那跟单线程有啥区别？嗯，区别就是多了线程切换的开销，反而更慢。

为什么会这样？我简单解释一下。Python的内存管理不是线程安全的，如果不加GIL，多个线程同时操作引用计数，内存分分钟崩掉。所以设计者选择了这把全局锁——牺牲多核并行能力，换来内存安全。

我在项目中遇到过这样一个场景：一个图像处理服务，用多线程去跑滤镜算法，结果8核机器只跑出了1.2倍的单核性能。排查了半天，发现GIL就是罪魁祸首。

3.2 多进程 vs 多线程：到底该怎么选？

这个问题其实不复杂。我个人的选择原则就一句话：看你的瓶颈在CPU上，还是在I/O上。

任务类型	推荐方案	原因
CPU密集型（计算、加密、图像处理）	多进程	每个进程有独立GIL，真正并行
I/O密集型（网络请求、文件读写、数据库）	多线程	GIL在I/O等待时会释放，线程开销小
混合型	多进程+协程	进程处理CPU，协程处理I/O

这里有个避坑指南：我曾经在一个爬虫项目里用了多进程，结果开了32个进程，每个进程都建立独立的数据库连接池，直接把数据库打挂了。后来改成多线程+连接池复用，问题就解决了。所以别盲目上多进程，进程间通信和资源开销你得算清楚。

3.3 使用concurrent.futures模块：优雅地管理并发

Python标准库里的concurrent.futures模块，是我个人最推荐的并发工具。它把线程池和进程池统一成了一个接口，用起来非常顺手。

先看一个多线程的例子，处理I/O密集型任务：

from concurrent.futures import ThreadPoolExecutor
import requests

def fetch_url(url):
    response = requests.get(url)
    return len(response.content)

urls = ["https://example.com"] * 10

with ThreadPoolExecutor(max_workers=4) as executor:
    results = list(executor.map(fetch_url, urls))

print(f"总下载字节数: {sum(results)}")

再看多进程版本，处理CPU密集型任务：

from concurrent.futures import ProcessPoolExecutor
import math

def is_prime(n):
    if n < 2:
        return False
    for i in range(2, int(math.sqrt(n)) + 1):
        if n % i == 0:
            return False
    return True

numbers = [15485863, 15485867, 15485869, 15485873]

with ProcessPoolExecutor(max_workers=4) as executor:
    results = list(executor.map(is_prime, numbers))

print(f"质数判断结果: {results}")

你看，代码结构几乎一模一样。唯一的区别就是ThreadPoolExecutor换成了ProcessPoolExecutor。这就是concurrent.futures的优雅之处——你只需要关心「我要并行执行什么」，而不需要关心底层是怎么调度的。

3.4 实战对比：多线程 vs 多进程跑CPU任务

我们来做个实验。计算1到10000000之间所有质数的个数，分别用单线程、多线程、多进程跑一次。

import time
import math
from concurrent.futures import ThreadPoolExecutor, ProcessPoolExecutor

def count_primes_in_range(start, end):
    count = 0
    for num in range(start, end):
        if num < 2:
            continue
        is_prime = True
        for i in range(2, int(math.sqrt(num)) + 1):
            if num % i == 0:
                is_prime = False
                break
        if is_prime:
            count += 1
    return count

# 单线程
start = time.time()
result = count_primes_in_range(1, 10000000)
print(f"单线程: {result} 个质数, 耗时 {time.time() - start:.2f} 秒")

# 多线程（4线程）
start = time.time()
with ThreadPoolExecutor(max_workers=4) as executor:
    futures = [executor.submit(count_primes_in_range, i*2500000+1, (i+1)*2500000+1) for i in range(4)]
    result = sum(f.result() for f in futures)
print(f"多线程: {result} 个质数, 耗时 {time.time() - start:.2f} 秒")

# 多进程（4进程）
start = time.time()
with ProcessPoolExecutor(max_workers=4) as executor:
    futures = [executor.submit(count_primes_in_range, i*2500000+1, (i+1)*2500000+1) for i in range(4)]
    result = sum(f.result() for f in futures)
print(f"多进程: {result} 个质数, 耗时 {time.time() - start:.2f} 秒")

结果会让你印象深刻：

• 单线程：约12秒
• 多线程：约13秒（反而更慢，因为GIL争抢和线程切换）
• 多进程：约3.5秒（接近4倍加速）

嗯，数据不会骗人。多线程在CPU密集型任务上不仅没提速，反而因为线程管理开销拖了后腿。而多进程真正做到了并行，接近线性加速。

3.5 知识体系总览

下面这张图帮你理清本章的核心逻辑：

这张图的核心逻辑很简单：先判断GIL对你的任务影响大不大。如果计算密集、GIL是瓶颈，走左边多进程；如果I/O密集、GIL会自动释放，走右边多线程。最后都通过concurrent.futures的统一接口来调度，代码写起来非常清爽。

3.6 总结与个人建议

聊了这么多，我总结几条实战经验：

• 别迷信多线程：Python的多线程在CPU密集型任务上基本是摆设。我见过太多人用多线程跑计算，结果性能还不如单线程。
• 多进程虽好，别贪多：进程数超过CPU核心数，性能反而下降。而且进程间通信（IPC）有开销，能用concurrent.futures就别自己手写multiprocessing的复杂逻辑。
• concurrent.futures是真香：它屏蔽了线程池和进程池的差异，代码迁移成本极低。从ThreadPoolExecutor换成ProcessPoolExecutor，只需要改一行。
• 实在不行，考虑C扩展：如果计算量实在太大，可以考虑用Cython、Numba或者直接写C扩展来绕过GIL。不过那是另一个话题了。

可可精品资料库