一、先认清战场：什么是CPU密集型任务？

CPU密集型任务，指的是那些计算时间占据绝对主导、几乎不存在I/O等待的工作负载。质数判断、矩阵运算、图像处理、加密解密——这些任务的共同特征是：CPU始终处于满载状态，每一个时钟周期都在被压榨。

在这种场景下，衡量并发模型优劣的核心指标只有一个：谁能更充分地利用多核CPU的并行计算能力？

而这，恰是三种模型分水岭最深的地方。

二、三种模型的底层逻辑差异

进程池：硬件级隔离的并行猛兽

进程是操作系统进行资源分配的基本单位。每一个进程拥有独立的虚拟地址空间，这意味着每个进程都持有一份独立的解释器实例和独立的全局解释器锁（GIL）。进程间通信虽然开销较大，但正因如此，多进程能够真正实现并行计算——每个进程在各自的CPU核心上跑，互不干扰。

创建进程涉及完整的地址空间建立，资源占用在MB级别，上下文切换开销在毫秒量级。这些数字看起来并不优雅，但在CPU密集型战场上，它们换来的是最朴素也最有效的东西：真正的并行。

线程池：被GIL锁住的尴尬选手

线程是操作系统调度的基本单元，同一进程内的所有线程共享地址空间和文件描述符。理论上，多线程应该能充分利用多核。然而，CPython解释器中的GIL如同一把无形的枷锁——同一时刻，只有一个线程能够执行Python字节码。

这意味着什么？在CPU密集型任务中，多个线程看似在并行运行，实则是在轮流抢占同一把锁。线程切换的开销在微秒级，而切换本身并不带来任何计算加速，反而因为频繁的上下文切换引入了额外损耗。测试数据显示，4个线程处理100万个数字的质数判断，耗时8.5秒，与单线程的8.7秒几乎持平。GIL让多线程在这个战场上几乎形同虚设。

协程池：用户态的轻量舞者

协程是用户态的轻量级线程，通过事件循环实现调度。协程的切换不需要陷入内核，开销仅为几十纳秒，内存占用低至KB级别。在I/O密集型场景中，协程的表现堪称惊艳——200个并发连接下，下载任务仅需2.59秒，性能提升接近3倍。

但在CPU密集型任务中，协程的命运截然不同。协程运行在单线程内，本质上是协作式的任务切换。当一个协程在进行密集计算时，它不会主动让出控制权，整个事件循环就会被阻塞。更关键的是，协程无法利用多核——所有协程挤在一个线程里，CPU的其他核心只能袖手旁观。测试数据同样印证了这一点：协程处理同样的质数判断任务，耗时8.6秒，与单线程几乎无异。

三、基准测试数据：数字不会说谎

为了让对比更加直观，我们设计了一组统一的测试：计算100万个数字的质数判断，分别用单线程、4线程、4进程、协程四种方式执行。结果如下：

数据触目惊心。在CPU密集型任务中，多进程以2.4秒的成绩遥遥领先，比多线程快了将近3倍，比协程快了超过3.5倍。而多线程和协程的表现几乎与单线程持平，这并非实现问题，而是模型本身的天花板。

另一组针对矩阵乘法（1024×1024浮点矩阵）的测试进一步验证了这一结论。在16至64并发范围内，线程模型的吞吐量随并发数增长较快，在64线程时达到峰值约1280 QPS。但当并发数超过128后，线程模型因上下文切换开销急剧下降。而在延迟指标上，协程虽然在低并发时表现尚可，但在64并发下95%延迟为18ms，仍比优化后的进程模型高出不少。更值得注意的是，线程模型在256并发时延迟飙升至120ms，而进程模型始终将延迟控制在45ms以内。

这些数据共同指向一个结论：在CPU密集型场景下，多进程是当之无愧的王者。

四、深入剖析：为什么会出现这种格局？

GIL是多线程的原罪

CPython的GIL确保同一时刻只有一个线程执行字节码。这一设计源于内存管理并非线程安全的历史包袱。在I/O密集型任务中，线程在等待I/O时会释放GIL，其他线程得以运行，因此多线程依然能带来收益。但在CPU密集型任务中，线程始终在争抢GIL，上下文切换的开销完全被浪费。

用一个形象的比喻：多线程就像四个人争用一把钥匙开门，无论几个人排队，同一时间只有一个人能进门。而多进程则是四个人各有一把钥匙，四扇门同时打开。

协程的单线程宿命

协程的调度完全由用户代码控制，运行在用户态，切换开销极低。但这种轻量的代价是：协程无法跨越线程边界去利用其他CPU核心。在CPU密集型任务中，协程就像一个技术精湛的独舞者——动作再快，也只能在一个舞台上表演。而多进程则是四个舞者各占一个舞台，真正实现并行。

进程的代价与回报

进程的上下文切换需要保存和恢复多达16个通用寄存器、程序计数器、栈指针等信息，开销在毫秒级。每个进程独立占用MB级内存。但在CPU密集型任务中，这些代价被并行计算带来的巨大收益所稀释。当任务是计算密集型时，每一毫秒的计算都在产出价值，进程切换的那几毫秒相对于整体运行时间而言，占比极小。

五、资源开销的全面对比

除了执行效率，资源消耗同样是工程选型的关键考量。

内存占用方面：进程池每个进程拥有独立的地址空间，占用在MB级别；线程池的每个线程默认栈空间约1MB；协程的初始内存占用仅为KB级别（典型值约2KB）。在资源受限的环境中，协程的内存优势极为突出，但这一优势在CPU密集型场景中毫无意义——因为协程根本跑不出性能。

CPU利用率方面：测试显示，线程模型在高并发时出现明显的CPU浪费，系统态开销约占15%，其中同步原语占用了12%的CPU时间。而进程模型的系统态开销控制在5%以内。协程模型虽然用户态调度使CPU利用率更集中，但由于无法利用多核，总吞吐量反而受限。

扩展性方面：协程可以轻松创建数万甚至数十万个实例，适合超高并发的I/O场景。线程数量通常控制在数百以内，过多会引发内存不足。进程数量则受限于CPU核心数，一般设置为核心数或核心数的2倍即可达到最优。

六、调优策略与最佳实践

基于上述测试结论，针对CPU密集型任务，给出以下工程建议：

第一，优先选择进程池。 将进程数设置为CPU核心数或核心数的1至2倍。过多的进程不会带来额外收益，反而因上下文切换和内存竞争降低整体性能。经验公式为：最优进程数等于CPU核心数乘以（1加上平均等待时间与平均计算时间的比值）。在纯CPU密集型场景中，该比值趋近于零，因此最优进程数约等于核心数。

第二，谨慎使用线程池。 除非运行在没有GIL限制的Python实现上，或者任务中混合了大量I/O操作，否则线程池在CPU密集型场景中几乎不产生收益。如果必须使用线程池，建议将线程数控制在CPU核心数附近，并配合无界队列以外的有界队列，避免内存膨胀。

第三，协程留给I/O密集型任务。 协程在网络请求、文件读写等场景中展现出颠覆性优势。200个并发连接下，协程的下载任务仅需2.59秒，而线程池需要7.46秒。但在CPU密集型任务中，协程的表现与单线程无异，不应被误用。

第四，混合场景可以组合使用。 例如，用多进程处理计算密集型的核心逻辑，每个进程内部用多线程或协程处理I/O操作。这种"进程做计算、线程做I/O"的组合策略，能够同时突破GIL限制和I/O瓶颈。

七、结语

回到最初的问题：CPU密集型场景下，谁是最优解？

答案已经无比清晰——进程池。它用毫秒级的切换开销和MB级的内存占用，换来了接近线性的多核并行加速。多线程被GIL锁死，协程被单线程困住，二者在这个战场上都只能望其项背。

但请记住，没有万能的并发模型。线程池在I/O密集型任务中依然是性价比极高的选择，协程在高并发网络服务中更是无人能敌。作为开发工程师，我们要做的不是迷信某一种模型，而是深刻理解每种模型的能力边界，在正确的战场上派出正确的部队。

性能优化的本质，从来不是追求极致的单一指标，而是在任务特征与模型能力之间找到那个最精准的契合点。