Python多线程因GIL无法利用多核CPU，仅适用于I/O密集型任务；多进程可真正并行但开销大，适合CPU密集型任务；选择取决于瓶颈类型（CPU或I/O）及数据共享需求。
Python多线程为什么跑不满CPU？
因为CPython有GIL（全局解释器锁），同一时刻只有一个线程执行Python字节码。哪怕你开了10个threading.Thread，纯计算任务（比如循环、数值运算）依然只能用上1个CPU核心。
适合场景：I/O密集型任务（如HTTP请求、文件读写、数据库查询），线程在等待响应时会释放GIL，让其他线程运行。
-
time.sleep()、requests.get()、open()等阻塞调用会自动让出GIL - 纯
for i in range(10**7): x += i这种计算不会让出，实际是串行执行 - 用
threading.active_count()可观察线程是否真在并发运行，但别靠它判断性能
Python多进程能真正并行，但开销大
multiprocessing.Process启动的是全新Python进程，每个都有独立内存和GIL，因此CPU密集型任务（如图像处理、加密、批量数据计算）能跑满所有核。
代价也很明显：进程创建/销毁比线程重；进程间通信（IPC）需通过Queue、Pipe或共享内存，不能直接传任意对象（得是可序列化的）。
立即学习“Python免费学习笔记（深入）”；
- 传递函数必须在模块顶层定义，不能是lambda或嵌套函数，否则
pickle失败报AttributeError: Can't pickle local object - 子进程默认不继承父进程的
logging配置、全局变量、数据库连接等，要重新初始化 - 用
multiprocessing.cpu_count()获取核心数，但并非越多进程越好——上下文切换和IPC开销会上升
怎么选？看任务类型+数据交换需求
不是“多线程快”或“多进程快”，而是“哪种更适合当前瓶颈”。关键判断点就两个：
- 瓶颈在CPU？→ 优先
multiprocessing（如科学计算、编码转码） - 瓶颈在等待I/O？→ 用
threading或更轻量的asyncio（如爬虫、API聚合） - 需要频繁共享大量数据？→ 谨慎用
multiprocessing.Manager()（慢），考虑multiprocessing.Array或sharedctypes（仅限简单类型）
混用也常见：主线程调度+多个进程做计算+线程池处理I/O回调，但调试难度陡增。
一个容易被忽略的坑：fork vs spawn
Linux/macOS默认用fork启动子进程（快，但会复制父进程整个内存空间，含已加载的模块状态）；Windows/macOS新版Python默认用spawn（从头导入模块，更干净但稍慢）。
问题来了：如果父进程中已经调用了torch.set_num_threads(1)或修改了os.environ，fork后子进程会继承这些设置；而spawn不会。
- 跨平台代码建议显式设置启动方法：
multiprocessing.set_start_method('spawn') - 尤其在使用PyTorch、TensorFlow等库时，不设可能引发CUDA上下文错误或线程数冲突
- 检查当前方法用
multiprocessing.get_start_method()
GIL、IPC方式、启动模型——这三块不摸清，光改Thread和Process名字没用。
