Python threading模块并行缓冲读取性能不佳原因分析

你遇到的这个问题核心原因就是CPython里大名鼎鼎的**全局解释器锁（GIL）**在起作用，结合你的测试场景和代码细节，我来一步步拆解：

1. GIL对CPU密集型线程任务的限制 #

CPython的GIL是一把全局锁，它保证同一时刻只有一个线程能执行Python字节码。哪怕你在多核CPU上运行多线程的Python代码，只要任务是纯CPU密集型（比如你代码里的process函数），这些线程也没法真正并行利用多核——它们只能交替占用CPU，而不是同时运行。

更糟的是，线程之间的切换还会带来额外开销（比如保存/恢复线程上下文、GIL的获取和释放），这就是为什么你看到线程数越多，整体性能反而下降的原因：单线程时没有切换开销，多线程时切换的消耗超过了“并行”带来的收益，甚至还不如单线程高效。

2. 你的代码正好是GIL的“重灾区” #

先看你的核心处理函数：

def process(i):
    for i in payloads[i]:
        j = i + 1

这是典型的纯CPU密集型任务——没有任何IO操作（文件读写、网络请求、休眠等），全程都是在执行Python字节码做计算。这种场景下，GIL几乎不会被主动释放（只有在特定时间片结束时才会短暂释放），所以多线程根本没法发挥并行作用，反而因为频繁切换拖慢了速度。

再看你的测试结果：

1 1.04805707932 1.05
2 1.45473504066 2.23
4 2.01357698441 3.98
8 1.56527090073 3.66
20 1.9085559845 4.15

单线程用时1秒左右，线程数增加到2时，实际运行时间直接跳到1.45秒，CPU时间（time.clock()的结果）更是翻倍到2.23秒——这正是多线程切换导致的额外消耗：两个线程在抢GIL、交替运行，总CPU时间是两个线程的时间总和，而实际墙钟时间因为切换开销反而变长了。

3. 为什么multiprocessing.Pool能有效加速？ #

multiprocessing.Pool是用多进程而非多线程实现并行的。每个进程都有自己独立的Python解释器和GIL，所以它们可以在多核CPU上真正并行运行——每个进程占用一个CPU核心，互不干扰。

对于CPU密集型任务来说，多进程能充分利用多核资源，所以你会看到随着进程数增加（不超过CPU核心数时），性能会线性提升，这和线程的表现完全相反。

4. 补充：什么时候threading有用？ #

如果你的任务是IO密集型（比如读取大量文件、发送网络请求、等待数据库响应），threading就会很有用。因为当一个线程在等待IO时，GIL会被释放，其他线程可以趁机执行代码，这样整体效率会提升。但你的场景是纯CPU计算，所以threading完全不适用。

总结建议 #

• 对于CPython中的CPU密集型任务，优先使用multiprocessing模块（或者concurrent.futures.ProcessPoolExecutor）来实现并行。
• 只有IO密集型任务，才适合用threading（或者concurrent.futures.ThreadPoolExecutor）。

内容的提问来源于stack exchange，提问作者wecx