Python多线程无法真正并行CPU计算，因CPython的GIL强制同一时刻仅一个线程执行字节码；I/O时GIL释放，故适合I/O密集任务；多进程通过独立解释器绕过GIL，实现多核并行，但开销大。
Python 多线程适合 I/O 密集型任务，多进程适合 CPU 密集型任务——核心区别在于 GIL（全局解释器锁）是否构成瓶颈。
为什么 Python 多线程无法真正并行执行 CPU 计算？
CPython 解释器存在 GIL，它保证同一时刻只有一个线程执行 Python 字节码。即使在多核 CPU 上，纯计算型线程也会被 GIL 强制串行化。
- 例如：用
threading.Thread启动 10 个线程各自做 10^7 次加法，总耗时接近单线程的 10 倍，而非接近 1 倍 - GIL 在 I/O 操作（如文件读写、网络请求、
time.sleep()）时会自动释放，所以多线程能高效并发处理请求 - 注意：C 扩展（如 NumPy 数组运算、正则匹配）在执行时可能主动释放 GIL，此时线程可真正并行
多进程如何绕过 GIL 实现真正的并行？
multiprocessing 模块为每个进程启动独立的 Python 解释器实例，每个进程拥有自己的 GIL 和内存空间，天然支持多核并行。
- 适合场景：图像处理、数值模拟、批量数据解析等 CPU 占用高的任务
- 代价是进程创建/通信开销大（比线程重），数据需序列化（
pickle），不能直接共享对象引用 - 常用方式：
multiprocessing.Process、Pool（推荐用于同构任务）、concurrent.futures.ProcessPoolExecutor
怎么选？看任务类型 + 数据交互需求
判断依据不是“要不要快”，而是“瓶颈在哪”和“要不要共享状态”。
立即学习“Python免费学习笔记（深入）”；
- I/O 密集（如爬虫、API 调用、日志轮转）→ 优先用
threading或asyncio（更轻量） - CPU 密集（如加密、渲染、机器学习推理）→ 必须用
multiprocessing或concurrent.futures.ProcessPoolExecutor - 需要跨任务共享大量数据 → 多进程可用
Manager、shared_memory（Python 3.8+）或队列；多线程直接用全局变量或threading.local - 混合型任务（如边下载边解压）→ 可组合使用：主线程调度 + 子进程做 CPU 工作 + 线程池做 I/O
面试常问延伸点
考官可能进一步追问底层机制或实际权衡：
- GIL 是 Python 的缺陷吗？ 不完全是——它简化了内存管理，提升单线程性能，且对 I/O 并发影响小；PyPy、Jython 等实现无 GIL，但生态和兼容性不同
- threading.local 是什么？ 为每个线程提供独立副本的属性容器，避免加锁，常用于请求上下文（如 Web 框架中的用户信息）
- 为什么 multiprocessing.Queue 比 threading.Queue 更重？ 前者基于管道或共享内存 + 序列化，后者只是线程间内存对象引用传递
-
有没有不依赖 multiprocessing 的 CPU 并行方案？ 有：调用 C/C++ 扩展（如 Cython + OpenMP）、使用
joblib（对 scikit-learn 友好）、或改用 Rust/Go 写核心模块再用 Python 调用
top 或 htop 观察 CPU 核心占用率，而不是只看 wall time —— 这才是验证是否真并行的最直接方式。 
