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，其他线程得以运行。
立即学习“Python免费学习笔记（深入）”；
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 <h1>IO 模拟：sleep 会释放 GIL，多线程有效加速</h1><p>def io<em>task(n): for </em> in range(n): time.sleep(0.001)</p><h1>CPU 模拟：math.sin 不触发系统调用，GIL 持有时间长</h1><p>def cpu<em>task(n): x = 0.1 for </em> in range(n): x = math.sin(x) + 0.001</p><h1>测试函数（略去计时包装）</h1><h1>结果：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
别试图用 threading 强行“优化” CPU 任务——这不是技巧问题，是模型误用。真正要学的不是怎么写更多线程，而是怎么识别任务类型，再选对抽象层。
