Python多线程适用于I/O密集型任务，因GIL在I/O调用时释放，可提升吞吐量；但对CPU密集型任务基本无效，应选multiprocessing或Numba等方案，并需谨慎处理线程安全与死锁。
Python多线程在I/O密集型任务中确实有用
CPython的全局解释器锁（GIL）让多线程无法真正并行执行CPU密集型代码，但这不等于多线程没价值。只要任务主要卡在等待网络响应、磁盘读写、数据库查询或用户输入上，threading就能显著提升吞吐量。
典型场景包括：同时发起多个HTTP请求、轮询多个串口设备、处理大量文件元信息（不读内容）、监听多个WebSocket连接。
-
requests.get()、time.sleep()、open()（仅打开/获取stat）、socket.recv()这类调用会主动释放GIL，线程可切换 - 用
concurrent.futures.ThreadPoolExecutor比手写threading.Thread更安全，自动管理线程生命周期和异常传播 - 线程数不是越多越好——通常设为
min(32, CPU核心数 * 4)或根据I/O延迟动态调整；超过一定数量反而因上下文切换增加开销
Python多线程对CPU密集型任务基本无效
如果你的代码主体是数值计算、图像处理、加密解密或正则反复匹配，threading几乎不会加快执行，甚至更慢。因为GIL强制这些操作串行执行，线程只是轮流抢锁，还多了调度成本。
错误现象：time.time()测出多线程版本比单线程还慢；top里Python进程始终只占100% CPU（单核满载）。
立即学习“Python免费学习笔记（深入）”；
- 替代方案优先选
multiprocessing，它绕过GIL，但注意进程启动开销和数据序列化成本 -
numba.jit或cython可将关键循环编译为机器码，在C层释放GIL，适合局部加速 - 用
asyncio配合await也能处理高并发I/O，且无线程切换开销，但需整个调用链支持异步
共享变量时线程安全必须手动保障
Python的list、dict等内置类型不是线程安全的。多个线程同时调用append()或__setitem__()可能引发数据丢失或KeyError，哪怕看起来只是“读多写少”。
常见误用：results.append(data)被多个线程并发调用，最终len(results)小于预期；counter += 1产生竞态，结果偏小。
- 简单计数用
threading.Lock保护，或直接换threading.local()做线程私有存储 - 避免用全局
dict缓存结果，改用queue.Queue——它内部已用锁封装，put()/get()天然线程安全 - 不要依赖
+=、del、in等看似原子的操作，它们在字节码层面往往拆成多步
调试多线程程序比想象中更难
问题往往不复现、不报错、只在特定负载下出现，比如偶尔丢数据、状态错乱、死锁。print()打点会干扰执行节奏，掩盖竞态；logging默认线程安全但输出顺序混乱，难以还原时序。
真实痛点：日志里看到A线程刚写入值，B线程就读到旧值，但加了time.sleep(0.001)后又正常了——这恰恰说明你撞上了未受保护的共享访问。
- 用
threading.settrace()或sys.settrace()做细粒度追踪，但性能损耗极大，仅限定位阶段 - 把可疑逻辑抽成纯函数，用
ThreadPoolExecutor.map()批量测试，更容易暴露边界条件 - 死锁排查优先检查
Lock.acquire()是否配对release()，以及嵌套锁顺序是否一致
多线程的价值不在“能不能跑”，而在“能不能稳住正确性的同时压住等待时间”。很多开发者卡在第一步就假设它该加速一切，结果掉进GIL认知偏差和竞态陷阱里——这两点比语法本身难得多。
