对纯计算密集型任务，用multiprocessing.pool或processpoolexecutor是最直接有效的提速方式；它绕开gil实现真并行，而threading.thread因gil限制实为串行，4个1秒任务总耗时仍近4秒，改用进程池可压至约1.1秒。
对纯计算密集型任务，用 multiprocessing.Pool 或 concurrent.futures.ProcessPoolExecutor 是最直接有效的提速方式；它绕开 GIL，让每个 CPU 核心真正并行干活。
为什么 multiprocessing.Pool 比 threading.Thread 快得多
Python 的 GIL（全局解释器锁）会让 threading.Thread 在 CPU 密集型任务中几乎串行执行——所有线程轮流抢同一个锁，实际吞吐不增反可能因上下文切换变慢。而 multiprocessing.Pool 启的是独立进程，每个进程有自己完整的 Python 解释器和内存空间，天然不受 GIL 限制。
- 常见错误现象：
threading.Thread跑 4 个各耗时 1 秒的计算，总耗时仍接近 4 秒；换成ProcessPoolExecutor后可压到约 1.1 秒（含进程启动开销） - 注意：进程间通信依赖
pickle序列化，所以传给pool.map的函数和参数必须可序列化——不能是lambda、嵌套函数、类实例方法、带闭包的函数等 - 小任务 + 高频调用时，进程创建/数据序列化开销可能吃掉并行收益，此时单进程反而更快
pool.map 和 pool.imap_unordered 的关键区别
两者都用于批量分发任务，但行为差异直接影响结果收集逻辑和内存占用：
Python 3.14.2
下载
Python 3.14.2是Python编程语言在2025年12月5日发布的稳定版本，属于3.14系列的第二个维护更新。该版本包含了18项修复，重点解决了多进程、数据类及正则表达式等模块的回归问题，并修复了CVE-2025-12084等安全漏洞。此版本标志着自由线程模式（移除GIL）正式获得官方支持，是Python发展的重要里程碑。
-
pool.map(func, iterable)：阻塞等待全部完成，返回完整结果列表；适合结果量小、需严格顺序处理的场景 -
pool.imap_unordered(func, iterable)：返回迭代器，结果按完成先后返回（不保序），内存友好；适合流式处理或想边算边用结果 - 别用
pool.apply_async手动管理callback+.get()—— 容易漏.get()导致子进程卡住，或忘记pool.close()/pool.join()
默认 max_workers 设置与资源陷阱
Pool 默认 max_workers 是 os.cpu_count()，但这只是理论最大值：
- 若任务本身已占满内存（比如每个进程加载大模型或大数组），开满核会触发频繁 swap，整体变慢
- 若任务涉及大量 I/O（如读写本地文件、调用外部命令），过多进程反而造成磁盘争抢
- 建议先用
os.cpu_count() // 2或min(4, os.cpu_count())起步，再根据实际 CPU 使用率和内存增长曲线调整
真正容易被忽略的是：即使你用了 Pool，如果函数里偷偷用了不可 pickle 的对象（比如某个自定义类的绑定方法、functools.partial 包了不可序列化对象），程序不会报错，而是静默退化成单进程执行——得靠 psutil 看进程数或加日志确认是否真并行。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
