Python多线程适用于I/O密集型任务（如HTTP请求、文件读写），因GIL在I/O时释放；对CPU密集型任务无效，应改用multiprocessing或asyncio。
Python多线程在I/O密集型任务中能有效提升效率，但对CPU密集型任务几乎无效——这是由全局解释器锁（GIL）决定的，不是代码写得不够好。
什么时候该用多线程？看任务类型
多线程适合等待时间长、计算少的场景，比如：发HTTP请求、读写文件、数据库查询、接收网络数据等。这些操作会主动释放GIL，让其他线程运行。
- 100个网页请求：用
threading或concurrent.futures.ThreadPoolExecutor可缩短总耗时近10倍（取决于网络延迟和线程数） - 逐行读取10个大日志文件：多线程比单线程快，因磁盘I/O期间线程切换频繁
- 但做100万次数学运算：开10个线程和1个线程耗时基本一样，甚至更慢（线程调度开销）
如何合理拆分任务？别盲目分太多
线程数不是越多越好。操作系统和Python都有资源上限，过多线程反而引发竞争、上下文切换频繁，拖慢整体速度。
- 一般设为CPU核心数的2–4倍（I/O越重，可适当提高），例如4核机器跑网络请求，8–16线程较稳妥
- 任务粒度要适中：把1000个请求拆成100组×10个，比拆成1000个独立任务更高效（减少线程创建/销毁和队列调度开销）
- 用
ThreadPoolExecutor自带的max_workers控制并发数，避免手动管理线程生命周期
常见陷阱：共享变量与线程安全
多个线程同时读写同一变量（如列表results.append(x)）可能丢失数据或报错，必须加锁或换线程安全结构。
立即学习“Python免费学习笔记（深入）”；
- 简单场景用
threading.Lock()保护临界区，例如计数器更新或结果收集 - 优先考虑队列：
queue.Queue天生线程安全，适合生产者-消费者模式 - 避免用全局列表/字典直接append/update；改用
with lock:包裹写操作，或改用concurrent.futures.as_completed()按完成顺序取结果
对比方案：什么情况下该换别的？
如果发现多线程提速不明显，先确认是不是CPU瓶颈；是的话，就该换方案了。
- CPU密集型任务 → 改用
multiprocessing（绕过GIL）或多进程+concurrent.futures.ProcessPoolExecutor - 高并发网络请求 → 考虑异步IO（
asyncio+aiohttp），内存占用更低、并发数更高 - 需要精细控制执行顺序或依赖关系 → 用
celery或dask这类任务调度框架，而非裸线程
多线程不是银弹，关键是匹配任务特征。看清是等资源，还是拼算力，再选工具。
