线程池与进程池对比解析

亲爱的编程学习爱好者，如果你点开了这篇文章，说明你对《ThreadPoolExecutor 与 ProcessPoolExecutor 使用对比》很感兴趣。本篇文章就来给大家详细解析一下，主要介绍一下，希望所有认真读完的童鞋们，都有实质性的提高。

IO密集型任务应优先用ThreadPoolExecutor，因其轻量、启动快、内存占用低；CPU密集型任务必须用ProcessPoolExecutor以绕过GIL；混合场景可分层协作，线程池处理IO、进程池处理CPU计算。

什么时候该用 ThreadPoolExecutor 而不是 ProcessPoolExecutor

IO 密集型任务（比如发 HTTP 请求、读写文件、数据库查询）基本都该优先选 ThreadPoolExecutor。CPython 的 GIL 会阻塞多线程的 CPU 计算，但对系统调用（如 read()、recv()）是释放的，线程在等 IO 时会交出控制权，让其他线程运行。

常见误判点：看到“并发”就下意识选进程池。其实只要任务主体是等待网络响应或磁盘读取，线程池更轻量、启动更快、内存占用低得多。

• HTTP API 批量调用（用 requests 或 httpx）→ ThreadPoolExecutor
• 遍历目录并读取几百个 JSON 文件 → ThreadPoolExecutor
• 同时向 Redis 写入大量键值 → ThreadPoolExecutor
• 纯数学计算（如矩阵乘法、加密哈希）→ 必须用 ProcessPoolExecutor

ProcessPoolExecutor 启动慢、传参受限的真实代价

每次提交任务到进程池，参数必须能被 pickle 序列化；函数本身得在模块顶层可导入；子进程无法共享主线程的上下文（比如已初始化的数据库连接、threading.local 变量、TLS 连接池）。

典型报错：AttributeError: Can't pickle local object 或 RuntimeError: Lock objects should only be shared between processes through inheritance。

• 避免在 ProcessPoolExecutor 中直接传 lambda、嵌套函数、类实例方法（除非用 functools.partial 拆解）
• 数据库连接不能复用，得在每个子进程中重新创建（或用连接池 + initializer 参数预建）
• 大对象（如 pandas DataFrame）传参会触发完整序列化/反序列化，可能比计算本身还慢

混合场景：怎么让线程池和进程池协作

没有“自动混合”的 Executor，但可以手动分层：用线程池处理 IO 部分，把 CPU 密集子任务扔给进程池。关键是要避免在子线程里再创建进程池（容易触发资源竞争或死锁）。

例如：下载 100 张图片（IO），每张下载完立刻做缩略图（CPU 密集）：

with ThreadPoolExecutor(max_workers=10) as tpe:
    futures = []
    for url in urls:
        # 线程负责下载
        future = tpe.submit(download_image, url)
        futures.append(future)
for future in as_completed(futures):
    img_bytes = future.result()
    # 下载完成后再交由进程池处理
    with ProcessPoolExecutor(max_workers=4) as ppe:
        ppe.submit(generate_thumbnail, img_bytes)

注意：这里 ProcessPoolExecutor 是在每个线程内临时创建的，适合短生命周期任务；若缩略图逻辑固定且频繁，建议把整个流程封装成独立函数，统一用进程池驱动，线程只做调度。

别忽略 max_workers 的实际效果

ThreadPoolExecutor 的 max_workers 不是越大越好——太多线程会加剧上下文切换开销，尤其在高并发 IO 场景下可能压垮远程服务或触发限流；ProcessPoolExecutor 则受限于 CPU 核心数，设成 os.cpu_count() * 2 通常无意义，反而增加 IPC 开销。

• HTTP 客户端常用 max_workers=10~30（取决于目标服务吞吐和超时设置）
• CPU 密集任务一般设为 os.cpu_count() 或 os.cpu_count() - 1
• 本地磁盘读写密集型（非 SSD）反而适合较小值（如 4~8），避免磁头频繁寻道

真正难的是压测时观察系统指标：线程池下看 CPU 是否闲置而响应延迟飙升（说明 IO 瓶颈）；进程池下看 CPU 使用率是否长期低于 70%（说明任务不纯 CPU 密集，或有隐藏 IO）。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《线程池与进程池对比解析》文章吧，也可关注golang学习网公众号了解相关技术文章。