Python多线程在I/O密集型任务中有效，但CPU密集型任务受GIL限制无法利用多核；应优先用ThreadPoolExecutor管理线程，共享数据需加锁或用queue.Queue，守护线程不保证执行完成。
Python 的多线程在 I/O 密集型任务中确实有用，但在 CPU 密集型任务中基本无效——这是由 GIL（全局解释器锁）决定的，不是写法问题，也不是优化能绕过的。
为什么 threading 跑不满多核 CPU
CPython 解释器为保证内存管理安全，同一时刻只允许一个线程执行 Python 字节码。GIL 会强制串行化 CPU 密集操作，哪怕你开了 10 个 Thread，sum([i**2 for i in range(10**7)]) 这类计算也几乎不会比单线程快。
- 验证方式：用
time.perf_counter()测多线程 vs 单线程纯计算耗时，结果通常接近甚至更慢（线程切换开销） - 真正受益的场景：发 HTTP 请求、读写文件、等待数据库响应——这些操作会自动释放
GIL - 替代方案：CPU 密集任务请直接换
multiprocessing或concurrent.futures.ProcessPoolExecutor
ThreadPoolExecutor 比原生 Thread 更实用
手动管理 Thread 对象容易出错：忘记 join()、异常未捕获、资源泄漏。而 ThreadPoolExecutor 自动处理生命周期和异常传播，适合绝大多数实际需求。
- 提交任务用
submit()（返回Future）或map()（批量、保序） - 默认线程数是
min(32, (os.cpu_count() or 1) + 4)，I/O 密集可适当调高，比如max_workers=20 -
Future.result()会阻塞，需配合timeout参数防卡死；异常会在调用result()时重新抛出
from concurrent.futures import ThreadPoolExecutor
import requests
def fetch_url(url):
return len(requests.get(url).content)
with ThreadPoolExecutor(max_workers=5) as executor:
futures = [executor.submit(fetch_url, u) for u in urls]
results = [f.result(timeout=10) for f in futures]
共享变量必须加锁，但别乱用 Lock
多个线程读写同一个字典、列表或自定义对象时，不加同步机制会导致数据错乱——这不是概率问题，是必然发生，只是时机难复现。
立即学习“Python免费学习笔记（深入）”；
- 简单计数用
threading.local()更轻量（每个线程独立副本），适合存储请求上下文、数据库连接等 - 真要跨线程共享状态，优先用
queue.Queue（线程安全）传数据，而不是裸露全局变量 -
Lock要成对出现：try/finally或with lock:，否则一旦异常跳过release()就死锁
守护线程（daemon=True）不是“后台服务”
设置 daemon=True 只表示：主线程退出时，该子线程会被强制终止，不管它是否跑完。它不提供任何后台保活、崩溃恢复或资源清理能力。
- 适合做日志轮转、心跳上报等“尽力而为”的辅助任务
- 绝对不能用于写文件、提交事务、关闭连接等需要确保完成的操作
- 若需优雅退出，应配合
threading.Event控制循环条件，并在主线程join()等待其自然结束
多线程真正的难点不在启动多少个线程，而在厘清哪些数据被谁读写、哪些操作必须原子、哪些阻塞不可接受——GIL 是限制，但竞态和逻辑混乱才是线上事故的常见源头。
