17370845950

Python多线程在I/O密集型任务中有效，但CPU密集型任务受GIL限制无法利用多核；应优先用ThreadPoolExecutor管理线程，共享数据需加锁或用queue.Queue，守护线程不保证执行完成。

Python 的多线程在 I/O 密集型任务中确实有用，但在 CPU 密集型任务中基本无效——这是由 GIL（全局解释器锁）决定的，不是写法问题，也不是优化能绕过的。

为什么 threading 跑不满多核 CPU

CPython 解释器为保证内存管理安全，同一时刻只允许一个线程执行 Python 字节码。GIL 会强制串行化 CPU 密集操作，哪怕你开了 10 个 Thread，sum([i**2 for i in range(10**7)]) 这类计算也几乎不会比单线程快。

• 验证方式：用 time.perf_counter() 测多线程 vs 单线程纯计算耗时，结果通常接近甚至更慢（线程切换开销）
• 真正受益的场景：发 HTTP 请求、读写文件、等待数据库响应——这些操作会自动释放 GIL
• 替代方案：CPU 密集任务请直接换 multiprocessing 或 concurrent.futures.ProcessPoolExecutor

ThreadPoolExecutor 比原生 Thread 更实用

手动管理 Thread 对象容易出错：忘记 join()、异常未捕获、资源泄漏。而 ThreadPoolExecutor 自动处理生命周期和异常传播，适合绝大多数实际需求。

• 提交任务用 submit()（返回 Future）或 map()（批量、保序）
• 默认线程数是 min(32, (os.cpu_count() or 1) + 4)，I/O 密集可适当调高，比如 max_workers=20
• Future.result() 会阻塞，需配合 timeout 参数防卡死；异常会在调用 result() 时重新抛出

from concurrent.futures import ThreadPoolExecutor
import requests

def fetch_url(url):
    return len(requests.get(url).content)

with ThreadPoolExecutor(max_workers=5) as executor:
    futures = [executor.submit(fetch_url, u) for u in urls]
    results = [f.result(timeout=10) for f in futures]

共享变量必须加锁，但别乱用 Lock

多个线程读写同一个字典、列表或自定义对象时，不

加同步机制会导致数据错乱——这不是概率问题，是必然发生，只是时机难复现。

• 简单计数用 threading.local() 更轻量（每个线程独立副本），适合存储请求上下文、数据库连接等
• 真要跨线程共享状态，优先用 queue.Queue（线程安全）传数据，而不是裸露全局变量
• Lock 要成对出现：try/finally 或 with lock:，否则一旦异常跳过 release() 就死锁

守护线程（daemon=True）不是“后台服务”

设置 daemon=True 只表示：主线程退出时，该子线程会被强制终止，不管它是否跑完。它不提供任何后台保活、崩溃恢复或资源清理能力。

• 适合做日志轮转、心跳上报等“尽力而为”的辅助任务
• 绝对不能用于写文件、提交事务、关闭连接等需要确保完成的操作
• 若需优雅退出，应配合 threading.Event 控制循环条件，并在主线程 join() 等待其自然结束

多线程真正的难点不在启动多少个线程，而在厘清哪些数据被谁读写、哪些操作必须原子、哪些阻塞不可接受——GIL 是限制，但竞态和逻辑混乱才是线上事故的常见源头。