Python多进程读取JSON时单进程耗时随进程数增加？原因解析

你的测试中，每个进程固定处理100个文件，但单进程耗时却随总进程数增加而变长，核心原因是系统资源竞争与调度开销，具体可拆解为以下几点：

1. 磁盘IO资源竞争 #

磁盘（包括SSD）的IO带宽是有限的。单进程读取时，磁盘可以全力响应其请求；但当数十甚至上百个进程同时发起文件读取操作时，所有进程会争抢IO资源，读取请求需要排队等待处理，直接导致单个进程的总读取耗时大幅增加。

你用的是10000个相同文件，文件系统可能有少量优化，但当进程数超过阈值后，IO队列的等待时间会显著上升，这是100进程场景耗时暴涨的主要原因。

2. 进程调度与上下文切换开销 #

操作系统需要在多个进程间分配CPU时间片。当进程数远大于CPU核心数时（比如6核Mac上跑100个进程），CPU会频繁进行上下文切换：保存当前进程状态、加载下一个进程状态，这个过程会消耗额外CPU时间，导致每个进程实际用于处理文件的有效时间被压缩，整体耗时自然变长。

即使是24核EC2实例，跑100个进程也会出现过度调度，每个进程的CPU时间片被分割得更细碎，累加的额外开销会明显体现在耗时上。

3. 文件系统缓存的“稀释”效应 #

单进程处理时，系统会将读取的文件内容缓存到内存，后续读取可直接命中缓存。但大量进程同时读取不同文件时，缓存会被快速填满并频繁替换，多数读取操作不得不回到磁盘，而非从内存缓存获取，这也会拉高单个进程的读取耗时。

4. 进程初始化与通信额外开销 #

创建大量进程本身会带来初始化开销（如内存分配、进程创建系统调用），同时multiprocessing.Pool在分发任务时存在少量进程间通信开销。这些开销会分摊到每个进程的处理时间中，进程数量越大，分摊的影响越明显。

验证建议 #

• 限制进程数不超过CPU核心数（比如6核机器跑6个进程），观察单进程耗时是否接近单进程场景的结果。
• 将文件全部迁移到内存文件系统（如Linux的tmpfs）中重复测试，排除磁盘IO的影响，此时耗时上升幅度会明显降低，主要体现调度开销。

内容的提问来源于stack exchange，提问作者broken.eggshell