为何ThreadPoolExecutor多线程解析JSON无性能提升？求替代方案

1. 代码逻辑错误（核心问题） #

你写的func函数是接收整个文件名列表并循环处理，但ThreadPoolExecutor.map的逻辑是把列表里的每个元素单独传给目标函数。这就导致每个线程拿到一个文件名后，又在func里遍历所有文件——等于每个线程都在重复执行完整的串行任务，最终总耗时和单线程完全一致，甚至因为线程切换额外增加开销。

2. Python GIL的限制（次要但关键） #

就算修正了逻辑，JSON解析属于CPU密集型任务，Python的全局解释器锁（GIL）会让同一时间只有一个线程执行字节码，多线程无法真正利用多核CPU并行计算，所以CPU密集场景下多线程根本提不了速。

先改对代码逻辑 #

把func改成只处理单个文件，让线程池的每个线程负责一个文件：

from concurrent.futures import ThreadPoolExecutor as th
import json

def process_single_file(file):
    with open(file, 'r', encoding='utf8') as f:
        x = json.loads(f.read())

N_THREADS = 2
file_names = [.....]  # 你的文件名列表

with th(N_THREADS) as ex:
    ex.map(process_single_file, file_names)

针对CPU密集任务用多进程 #

如果修正后还是没提速，直接换多进程——多进程能绕过GIL，真正利用多核CPU并行处理：

from concurrent.futures import ProcessPoolExecutor as pp
import json

def process_single_file(file):
    with open(file, 'r', encoding='utf8') as f:
        x = json.loads(f.read())

N_PROCESSES = 4  # 建议设为你的CPU核心数
file_names = [.....]

with pp(N_PROCESSES) as ex:
    ex.map(process_single_file, file_names)

额外说明 #

如果你的文件是在网络存储上（IO等待时间远大于CPU解析时间），多线程还是有用的——因为线程等待IO时会释放GIL，让其他线程干活。但本地文件IO通常很快，此时JSON解析的CPU占比更高，多进程才是正确选择。

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