Python多线程提速仅适用于I/O密集型任务，因GIL在I/O等待时释放；CPU密集型任务应选multiprocessing或asyncio；共享变量须用Lock或queue.Queue保障线程安全。
Python多线程不是“开多个线程就能加速”，关键在理解GIL、共享状态和任务分发逻辑。真正用好多线程，得先跳出“只要threading.Thread()就并发”的误区，从执行模型、数据安全、适用场景三层入手。
GIL到底锁什么？什么时候它不拖后腿？
GIL（全局解释器锁）只限制同一时刻只有一个线程执行Python字节码，但它不锁系统调用、I/O等待、C扩展中的计算。这意味着：
- 纯CPU密集型任务（如数学运算、循环处理）几乎无法通过多线程提速，因为线程总在争抢GIL；
- 但涉及网络请求（requests）、文件读写（open/read）、数据库查询（sqlite3.execute）等I/O操作时，线程会在等待期间主动释放GIL，让其他线程运行——这才是多线程真正发挥价值的场景；
- 若需CPU并行，应改用multiprocessing或异步IO（asyncio），而非硬扛threading。
共享变量怎么不丢数据？别靠“我试试看”
多个线程读写同一变量（如计数器、列表、字典）极易出错——不是偶尔错，而是必然错，只是时机不确定。根本原因：赋值、append、+=等操作不是原子的。
- 用threading.Lock保护临界区：获取锁→操作变量→释放锁；
- 优先使用线程安全的数据结构：queue.Queue（天生线程安全，适合生产者-消费者模型）；
- 避免全局可变状态，尽量把数据封装进单个线程内处理，或用threading.local()为每个线程提供独立副本。
实战案例：爬100个网页，为什么开10线程比开100更快？
这是一个典型I/O密集型任务。看似线程越多越快，实则受系统资源（文件描述符、端口、DNS缓存）和目标网站反爬策略制约。
- 用concurrent.futures.ThreadPoolExecutor控制最大并发数（如max_workers=10），比手动管理Thread更简洁可靠；
- 配合requests.Session()复用连接，显著减少握手开销；
- 加简单重试+超时（timeout=10），避免单个失败请求卡住整个线程；
- 结果统一用queue.Queue收集，主线程最后取值，避免竞争。
调试多线程程序的三个实用技巧
线程问题难复现、难定位，靠print容易干扰执行流。更有效的方式是：
- 用threading.enumerate()和threading.current_thread().name实时查看活跃线程与身份；
- 在关键位置加logging（非print），配置格式包含线程名，例如%(threadName)s；
- 怀疑死锁？临时加Lock.acquire(timeout=2)，超时抛异常，快速暴露阻塞点。
