17370845950

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)）可能丢失数据或报错，必须加锁或换线程安全结构。

• 简单场景用threading.Lock()保护临界区，例如计数器更新或结果收集
• 优先考虑队列：queue.Queue天生线程安全，适合生产者-消费者模式
• 避免用全局列表/字典直接append/update；改用with lock:包裹写操作，或改用concurrent.futures.as_completed()按完成顺序取结果

对比方案：什么情况下该换别的？

如果发现多线程提速不明显，先确认是不是CPU瓶颈；是的话，就该换方案了。

• CPU密集型任务 → 改用multiprocessing（绕过GIL）或多进程+concurrent.futures.ProcessPoolExecutor
• 高并发网络请求 → 考虑异步IO（asyncio+aiohttp），内存占用更低、并发数更高
• 需要精细控制执行顺序或依赖关系 → 用celery或dask这类任务调度框架，而非裸线程

多线程不是银弹，关键是匹配任务特征。看清是等资源，还是拼算力，再选工具。