Python并发性能瓶颈在于I/O模型、GIL限制和任务特性误判；需用cProfile、strace、psutil等工具定位CPU/ I/O/锁真实瓶颈，再依任务类型选择multiprocessing、asyncio或混合策略，并避免全局锁与资源滥用。
Python并发性能瓶颈往往不在代码写法本身，而在于对I/O模型、GIL限制和任务特性的误判。调优前必须先定位真实瓶颈——是CPU密集？还是I/O等待？或是锁竞争？盲目加线程/协程反而让性能更差。
识别真实瓶颈：别猜，用工具看
先运行实际负载，用标准库和第三方工具采集数据：
- cProfile 或 py-spy 查CPU热点：确认是否真卡在计算逻辑（如循环、正则、JSON解析），还是只是“看起来慢”
- strace -e trace=epoll_wait,read,write,connect（Linux）观察系统调用阻塞时长，判断I/O是否堆积
- threading.setprofile() 或 asyncio.get_event_loop().set_debug(True) 检查线程/协程是否频繁挂起、调度延迟高
- 用 psutil 监控进程的 CPU%、线程数、文件描述符使用量，排除资源耗尽（如1024连接打满）
CPU密集型任务：绕不开GIL，就得换方案
纯计算任务（如图像处理、数值模拟）用 threading 或 asyncio 不会提速，反而因上下文切换更慢：
- 优先用 multiprocessing 或 concurrent.futures.ProcessPoolExecutor 拆分任务
- 关键计算部分用 Cython 或 numba.jit 编译加速，释放GIL
- 避免在子进程中频繁传大对象——用 shared_memory 或内存映射减少拷贝开销
- 注意进程启动成本：短任务别为每个请求启新进程，改用进程池复用
I/O密集型任务：选对模型比堆数量更重要
HTTP请求、数据库查询、文件读写等场景，瓶颈在等待响应，不是Python执行速度：
立即学习“Python免费学习笔记（深入）”；
- 同步阻塞（requests + threading）适合简单脚本，但线程数超过OS能高效调度的阈值（通常50–100）后吞吐不增反降
- 异步非阻塞（aiohttp + asyncio）单线程可支撑数千并发，但要求所有I/O操作都异步化（包括DB驱动要用 asyncpg / aiomysql）
- 混合策略更实用：用 asyncio.to_thread() 包装少量同步阻塞调用（如调用旧版SDK），避免阻塞整个事件循环
- 连接池必须配合理使用：aiohttp.TCPConnector(limit=100) 防止瞬时打爆目标服务
锁与共享状态：并发安全不等于性能安全
多线程/多协程共用变量时，加锁虽保安全，却可能成为新瓶颈：
- 避免全局锁（如用 threading.Lock() 锁整个数据结构），改用细粒度锁或无锁结构（queue.Queue、asyncio.Queue）
- 计数类操作优先用 threading.local() 或 contextvars.ContextVar 做线程/协程局部存储，消除竞争
- 高频读+低频写的场景，用 functools.lru_cache() 或 cached_property 减少重复计算，比锁更轻量
- 日志、指标上报等旁路操作，改用队列+单独消费者线程处理，别在主逻辑里直接写磁盘或发网络
不复杂但容易忽略。调优不是堆并发数，而是让每一分资源用在刀刃上——该等的时候等得聪明，该算的时候算得彻底，该共享的时候共享得克制。
