cpython的gil强制多线程串行执行python字节码，cpu密集型任务中线程切换和锁争抢反拖慢速度，故几乎无效。
多进程能绕过 GIL，但不是只要用了 multiprocessing 就自动变快——关键在任务类型、数据传递方式和进程启动开销。
为什么 threading 对 CPU 密集型任务几乎没用
CPython 的 GIL 强制所有线程轮流执行 Python 字节码，哪怕四核 CPU 也只有一个线程真正在算。你写个循环累加 10**7 次，开 4 个 threading.Thread，总耗时通常比单线程还长，因为线程切换+GIL 争抢反而拖慢了节奏。
常见错误现象：
- 用
threading跑图像缩放、矩阵乘法、密码哈希，结果速度没提升，CPU 使用率卡在 100% 却只占一个核 - 误以为“开了多个线程 = 并行”，实际是并发（concurrent），不是并行（parallel）
Process 和 Pool 怎么选
Process 是底层接口，适合控制单个子进程行为；Pool 是高层封装，适合批量同构任务，省去手动管理生命周期的麻烦。
使用场景差异：
- 用
Process：需要自定义子进程启动逻辑、捕获特定信号、或子任务间状态强隔离（比如每个进程加载不同模型） - 用
Pool：对一批数字求平方、解析上百个日志文件、批量调用同一函数处理不同输入——这时pool.map()或pool.apply_async()更简洁
注意点：
Python 3.14.2是Python编程语言在2025年12月5日发布的稳定版本，属于3.14系列的第二个维护更新。该版本包含了18项修复，重点解决了多进程、数据类及正则表达式等模块的回归问题，并修复了CVE-2025-12084等安全漏洞。此版本标志着自由线程模式（移除GIL）正式获得官方支持，是Python发展的重要里程碑。
-
Pool默认启动进程数等于os.cpu_count()，但并非越多越好；I/O 等待多的任务反而可能因上下文切换变慢 - 传给
Process或Pool的函数必须能被主模块 import，不能是闭包或 lambda（否则子进程反序列化失败） - Windows 下必须用
if __name__ == '__main__':包裹启动代码，否则会递归创建新进程
进程间通信别直接读全局变量
每个进程有独立内存空间，主进程里定义的 list、dict、类实例，在子进程中完全不可见——这不是 bug，是设计使然。
正确做法：
- 只传必要参数：把输入数据序列化后通过
args或kwargs传进去，返回结果由父进程收集 - 用
Queue或Pipe做流式通信：适合生产者-消费者模式，比如一边读文件、一边解析、一边写库 - 共享简单状态用
Value或Array：仅支持基础类型（c_int、c_double等），且需加锁（Lock）避免竞态
典型错误：
- 在子进程中修改主进程的
global counter，运行完发现值没变 - 把大对象（如 pandas DataFrame）塞进
Queue，触发 pickle 失败或性能骤降
实际提速受哪些因素拖累
多进程不是银弹。真实加速比常低于理论值，尤其在以下情况：
- 任务本身太小：比如每个子任务只跑几毫秒，进程启动/IPC 开销就盖过了计算收益
- 数据太大要序列化：传入 500MB 的 numpy 数组，pickle + 反序列化时间可能比计算还久
- 磁盘 I/O 成瓶颈：多个进程同时读同一个 SSD，随机读性能反而下降
- 内存吃紧：每个进程都复制一份模型权重，16GB 内存跑 8 个进程直接 OOM
建议先用 time.perf_counter() 测单任务耗时，再粗略估算：若单任务 > 100ms，且无大块数据传递，multiprocessing 才大概率带来收益。
最容易被忽略的一点：子进程崩溃不会自动抛到主进程，得主动检查 p.exitcode 或用 pool.apply_async(..., error_callback=...) 捕获异常。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
