ThreadPoolExecutor不能突破GIL，CPU密集型任务下多线程实为串行执行，仅单核满载；真正压满多核须改用ProcessPoolExecutor等进程模型。
ThreadPoolExecutor 不能突破 GIL，CPU 密集型任务用它只会卡在一个核上跑 —— 想真正压满多核，必须换进程模型。
为什么 threading 和 ThreadPoolExecutor 都跑不满多核
CPython 的 GIL 是个独占锁：任意时刻只允许一个线程执行 Python 字节码。哪怕你启了 8 个线程，在纯计算场景下（比如循环、数学运算），它们实际是轮流抢锁、串行执行的。
常见错误现象：
-
psutil.cpu_percent()显示单核 100%，其余核长期低于 5% - 任务耗时几乎不随线程数增加而下降，甚至变慢（上下文切换开销）
- 用
top或活动监视器看，Python 进程只有一个 CPU 时间片在增长
注意：I/O 密集型任务（如 HTTP 请求、文件读写）不受此限，因为系统调用会主动释放 GIL，此时多线程仍有效。但只要代码主体是计算，就别指望它并行。
立即学习“Python免费学习笔记（深入）”；
用 multiprocessing 替代 threading 的关键改法
进程间不共享 GIL，每个子进程拥有独立解释器和内存空间，天然支持多核并行。但要注意接口和数据传递方式变化：
- 函数必须可被 pickle 序列化（不能是嵌套函数、lambda、类实例方法）
- 参数和返回值也得能被
pickle，大对象传参前考虑用multiprocessing.shared_memory或queue -
if __name__ == "__main__":保护必不可少，否则 Windows/macOS 下会反复 fork 主模块 - 启动方式推荐
mp.set_start_method('spawn')，尤其涉及多线程或 C 扩展时，避免fork引发的死锁或状态污染
示例对比（质数判断）：
# 错误：用 ThreadPoolExecutor 处理 CPU 密集型任务
from concurrent.futures import ThreadPoolExecutor
with ThreadPoolExecutor(max_workers=4) as ex:
list(ex.map(is_prime, numbers)) # 实际还是单核忙
<h1>正确：换成 ProcessPoolExecutor</h1><p>from concurrent.futures import ProcessPoolExecutor
with ProcessPoolExecutor(max_workers=4) as ex:
list(ex.map(is_prime, numbers)) # 四核齐动
multiprocessing.Pool 和 ProcessPoolExecutor 怎么选
两者底层都基于 multiprocessing，区别在抽象层级和使用习惯：
-
Pool更底层，提供apply/map/starmap等同步/异步接口，适合批量同构任务 -
ProcessPoolExecutor是concurrent.futures统一接口的一部分，与ThreadPoolExecutor行为一致，便于在 I/O/CPU 任务间切换（只需改 import 和类名） - 若需细粒度控制子进程生命周期（如手动管理 worker 进程、设置超时、取消任务），优先用
ProcessPoolExecutor - 若已有大量基于
Pool的老代码，且无 executor 特性需求，不必强改
性能差异极小，选哪个主要看团队编码规范和后续扩展性。
容易被忽略的坑：数据序列化开销和内存复制
多进程不是银弹。每次传参、取结果都要走 pickle → 序列化 → 进程间通信 → 反序列化流程：
- 传入一个 100MB 的
numpy.ndarray，会被完整拷贝 4 次（4 个 worker 各一份），而不是共享 - 频繁小任务 + 大参数 = 开销反超收益，此时应合并任务粒度，或改用
multiprocessing.shared_memory（Python 3.8+） - Windows 下默认启动方式是
spawn，但 Linux/macOS 默认是fork；若子进程里用了多线程或某些 C 库（如 OpenMP），fork可能引发死锁，务必显式设为spawn
重构时最常漏掉的，就是没测数据传输成本 —— 先用 time.perf_counter() 分段打点，确认瓶颈真在计算，而不是 pickle 或 IPC 上。
