Python多线程系统学习路线第536讲_核心原理与实战案例详解【技巧】_技术教程

Python多线程无法并行执行CPU密集型任务，因CPython的GIL强制字节码串行执行；仅IO密集型任务能受益，因其等待时释放GIL；CPU密集型应选multiprocessing或asyncio。

Python 的多线程并不真正并行执行 CPU 密集型任务，这是由 GIL（全局解释器锁）决定的——它让同一时刻只有一个线程执行 Python 字节码。

为什么 threading 模块跑不满多核？

根本原因不是代码写得不对，而是 CPython 解释器的设计选择：为内存管理安全，GIL 会强制串行化字节码执行。即使你开了 8 个 threading.Thread，CPU 密集型运算（如数值计算、加密、递归）依然只占用一个逻辑核心。

常见错误现象：

用 time.time() 测总耗时，发现 4 线程版本比单线程还慢
top 或任务管理器里 CPU 使用率始终卡在 100%（单核满载），而非 400%
线程数调到 os.cpu_count() 以上毫无收益，甚至因上下文切换拖慢整体

适用场景反而是：IO 密集型 操作（文件读写、网络请求、数据库查询）。此时线程在等待响应时会主动释放 GIL，其他线程得以运行。

threading.Thread 的关键参数与陷阱

最常被忽略的是 daemon 参数，默认为 False。非守护线程会阻塞主程序退出，哪怕主线程执行完了，只要还有非守护子线程在跑，Python 进程就不会结束。

实操建议：

后台轮询、日志上报等不需等待完成的任务，显式设 daemon=True
涉及资源清理（如关闭文件、断开连接）的线程，务必保持 daemon=False，并用 join() 显式等待
避免在 __init__ 中直接启动线程；应先实例化，再调 start() —— 否则异常可能发生在构造过程中，难以捕获
target 函数若抛出未捕获异常，该线程静默死亡，不会传播到主线程，也无 traceback 输出（除非重写 run() 并加 try/except）

如何验证 GIL 的影响？用 time.sleep 和 math.sin 对比

下面两个例子能直观体现 GIL 的“开关”效果：

import threading
import time
import math
IO 模拟：sleep 会释放 GIL，多线程有效加速
def iotask(n):
for  in range(n):
time.sleep(0.001)
CPU 模拟：math.sin 不触发系统调用，GIL 持有时间长
def cputask(n):
x = 0.1
for  in range(n):
x = math.sin(x) + 0.001
测试函数（略去计时包装）
结果：io_task 多线程耗时 ≈ 单线程 / 线程数；cpu_task 多线程耗时 ≈ 单线程 × 1.1~1.3（因调度开销）

注意：math.sin 是纯 Python 调用的 C 函数，但它不释放 GIL；而 time.sleep 是系统调用，会主动让出 GIL。这种差异正是判断某操作是否受 GIL 制约的关键线索。

替代方案：什么时候该换 multiprocessing 或 asyncio？

当你的任务确实是 CPU 密集型，且必须提速时，threading 就是错的选择。此时应考虑：

multiprocessing.Process：绕过 GIL 的最直接方式，每个进程有独立解释器和内存空间，适合数据可序列化、任务边界清晰的场景
concurrent.futures.ProcessPoolExecutor：比裸用 multiprocessing 更简洁，支持 map、submit 和统一异常处理
asyncio：适用于高并发 IO（如万级 HTTP 请求），但要求所有调用都是异步的（aiohttp、aiomysql），同步库（requests、sqlite3）会阻塞整个 event loop