Python多线程仅对I/O密集型任务有效，因GIL使CPU密集型任务仍串行执行；推荐用ThreadPoolExecutor配5–20线程，注意异常捕获与共享变量加锁。
Python多线程在I/O密集型任务中确实能提效
CPython的全局解释器锁（GIL）让多线程无法真正并行执行CPU密集型代码，但对文件读写、网络请求、数据库查询等I/O操作，线程会在等待时主动释放GIL，让其他线程运行。这意味着：requests.get()、time.sleep()、open() 等阻塞调用场景下，多线程能显著缩短总耗时。
实操建议：
- 用
threading.Thread或concurrent.futures.ThreadPoolExecutor启动 5–20 个线程通常足够，过多反而因上下文切换增加开销 - 避免在线程中做大量数值计算（如矩阵乘法、循环累加），这类任务应改用
multiprocessing - 共享变量需加
threading.Lock，否则可能产生竞态——比如多个线程同时修改一个list.append()而未同步
为什么CPU密集型任务用多线程反而更慢
因为GIL强制同一时刻只有一个线程执行Python字节码。即使开了10个线程跑 sum(range(10**7))，实际仍是串行执行，还额外承担了线程创建、调度、内存隔离的成本。
常见错误现象：
立即学习“Python免费学习笔记（深入）”；
- 用
threading加速图像缩放、文本分词、加密解密等操作，结果比单线程还慢 20%–50% - 误以为“开了8个线程就能吃满8核”，实际
top显示CPU使用率始终卡在100%（单核满载）
替代方案：直接换 multiprocessing.Process 或 concurrent.futures.ProcessPoolExecutor，绕过GIL限制。
ThreadPoolExecutor 的 max_workers 怎么设才合理
这个参数不是越大越好，也并非必须等于CPU核心数。它本质是控制并发请求数量，和系统资源、目标服务限流策略强相关。
实操建议：
- 对外发起HTTP请求时，
max_workers=10常比100更稳——很多API会因并发过高返回429 Too Many Requests - 读本地小文件时，
max_workers=4通常已接近磁盘I/O极限，再高无收益 - 若任务含不透明的第三方库调用（如某些SDK内部含阻塞C扩展），先用
time.perf_counter()测单任务耗时，再按总期望并发数 ≈ 期望吞吐 / 单任务平均耗时反推
容易被忽略的陷阱：线程安全与异常传播
多线程环境下，未捕获异常不会中断主线程，而是静默消失；而共享状态若没保护，结果可能随机出错。
关键细节：
-
ThreadPoolExecutor.submit()返回的Future对象，必须显式调用.result()才会抛出子线程里的异常，否则错误被吞掉 -
list、dict等内置类型不是线程安全的——threading.local()可为每个线程提供独立副本，比手动加锁更轻量 - 日志写入（如用
logging.info()）在多线程下默认是安全的，但自定义的文件写入逻辑必须自己加锁
真实项目里，80%的“多线程变慢”或“结果错乱”问题，都出在没检查 Future.result() 或忘了保护共享数据结构。
