python多线程无法提升cpu密集型任务性能，根本原因是cpython的gil强制同一时刻仅一个线程执行字节码，导致多线程在纯计算场景下串行执行、竞争锁并产生额外开销；而io密集型任务因阻塞时自动释放gil，多线程仍可高效并发。
多线程吞吐量上不去，大概率不是代码写得不好，而是你正让 threading 去干它根本干不了的活——比如纯计算。GIL 不是 bug，是 CPython 的内存安全契约；优化它的竞争，本质是减少“抢锁”、避开“锁争”，而不是试图“打败”它。
判断任务类型：IO密集型还是CPU密集型？
这是所有决策的起点。GIL 只在 CPU 密集型任务里成为瓶颈，在 IO 密集型中它反而是帮手——因为线程一遇到 socket.recv()、open().read()、time.sleep() 就自动释放锁，其他线程立刻能上。
- 典型 IO 密集型：
requests.get()、psycopg2.execute()、open("large.log").readlines()、redis.get() - 典型 CPU 密集型：
sum([x**2 for x in range(10**7)])、np.fft.fft2(img)、is_prime(n)、任何没 I/O 的纯循环/数学运算 - 混淆点：
pandas.merge()看似 IO，实为 CPU 密集；json.loads()解析大字符串也是 CPU 密集
IO密集型任务：用好 threading + 限制并发数
多线程在这里有效，但盲目开几百个线程只会加剧 GIL 切换开销，反而拖慢整体吞吐。关键不是“越多越好”，而是“够用且稳定”。
- 网络请求类任务，
max_workers=10~30通常是合理起点（远高于 CPU 核心数也没问题） - 数据库连接池要匹配线程数，避免
OperationalError: too many clients - 避免在线程内做耗时同步操作（如
print()大量日志），它会阻塞 GIL 释放时机 - 推荐用
concurrent.futures.ThreadPoolExecutor而非裸threading.Thread，它内置了任务队列和异常传播
CPU密集型任务：别硬刚GIL，换进程或C扩展
用 threading 跑纯计算，4 线程可能比 1 线程还慢——不是你的错，是 GIL 切换+上下文开销盖过了并行收益。此时唯一靠谱路径是绕开 GIL。
- 首选
multiprocessing或concurrent.futures.ProcessPoolExecutor：每个进程有独立 GIL，真并行 - 注意数据序列化成本：
pickle大对象传参很慢，考虑用mmap或共享内存（multiprocessing.shared_memory） - 对性能极致敏感场景，用
Cython在nogil块里写核心循环，手动释放 GIL（但需 C 基础） - Python 3.13+ 的 free-threaded build 是新选项，但它需要重新编译解释器、不兼容多数 C 扩展，生产环境慎用
共享状态导致的数据错乱：比性能更隐蔽的坑
很多人调了半天吞吐量，最后发现结果错了——counter += 1 这种操作在多线程下天然不安全，GIL 并不保证它原子。这不是“竞争太激烈”，而是设计如此。
-
threading.Lock能解决，但易写错、易死锁，不是第一选择 - 优先用
queue.Queue做线程间通信：它内部已加锁，put()/get()全线程安全 - 避免全局变量，改用函数参数传递或
threading.local()维护线程私有状态 - 若必须累加数值，用
threading.atomic（Python 3.12+）或numpy的原子操作替代
真正难的不是“怎么写多线程”，而是每次写之前，先问一句：这个函数执行时，CPU 在忙什么？如果答案是“几乎不等 IO”，那 threading 就不该出现在调用栈里。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
