对纯计算密集型任务，必须用multiprocessing.pool或processpoolexecutor才能真正并行；因threading受gil限制实为串行，4线程计算耗时≈单线程×4，而4进程可压至约1.1秒。
因为 threading 在 CPU 密集型任务中根本无法并行——GIL 强制所有线程串行执行，而 multiprocessing 启动独立进程，每个都有自己的 Python 解释器和 GIL，天然绕过限制。
threading 跑计算密集型任务时实际是串行的
你写 4 个 Thread 去算斐波那契、矩阵乘法或循环累加，耗时几乎等于单线程跑 4 次。不是“慢一点”，而是“基本不提速”。典型现象：time.time() 测出来总耗时 ≈ 单任务耗时 × 任务数。
- GIL 只在 I/O 等待时释放，纯计算过程中它一直被占用
- 线程切换反而增加上下文开销，有时比单线程还慢
- 哪怕机器有 32 核，
threading也只用到 1 个核
multiprocessing 是唯一能真正并行的方案
每个 Process 或 ProcessPoolExecutor 子进程拥有独立内存、独立 GIL、独立解释器，CPU 密集型任务可分摊到多核上跑。实测常见场景：4 个耗时 1 秒的数值计算，用 ProcessPoolExecutor 后总耗时压到约 1.1–1.3 秒（含启动开销）。
Python 3.14.2是Python编程语言在2025年12月5日发布的稳定版本，属于3.14系列的第二个维护更新。该版本包含了18项修复，重点解决了多进程、数据类及正则表达式等模块的回归问题，并修复了CVE-2025-12084等安全漏洞。此版本标志着自由线程模式（移除GIL）正式获得官方支持，是Python发展的重要里程碑。
- 必须确保传入函数和参数可被
pickle（不能是lambda、嵌套函数、实例方法） - 小任务高频调用时，进程创建 + 序列化开销可能反超收益，此时不如单进程
-
max_workers设太高会吃光内存，尤其处理大 NumPy 数组时易触发 swap
别误用 asyncio 或 run_in_executor 补救
asyncio 对纯计算完全无效：await cpu_bound_func() 不会让出控制权，整个事件循环卡死；loop.run_in_executor() 或 asyncio.to_thread() 是兜底手段，本质还是靠线程池——它解决不了 GIL 问题，只是把阻塞扔进后台线程，对 CPU 密集型任务提速有限且增加复杂度。
- 第三方库如
numpy底层 C 实现虽能绕部分 GIL，但 Python 层循环、条件判断、对象构造仍受锁限制 - 想靠
threading+concurrent.futures.ThreadPoolExecutor加速计算？结果和裸写Thread一样，白忙
真正要注意的不是“该不该换”，而是“什么时候换得不偿失”：任务太小、数据太大、通信太频——这些边界情况比选错模块更容易拖垮性能。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
