Python并发优化核心是先识别I/O等待、GIL限制、共享资源争用、任务粒度失衡四类瓶颈；需用cProfile/py-spy定位阻塞点，区分计算与I/O任务选合适模型，避免锁滥用，合理控制任务粒度。
Python并发架构优化的核心，不是盲目上多线程或多进程，而是先找准瓶颈——I/O等待、GIL限制、共享资源争用、任务粒度失衡，这四类问题覆盖了90%的性能卡点。
识别真实瓶颈：别被CPU占用率骗了
很多服务CPU使用率很低，但响应慢、吞吐上不去，本质是I/O阻塞（如数据库查询、HTTP调用、文件读写）占了大部分时间。用cProfile + asyncio.profiler或py-spy record抓取运行时栈，重点关注长时间停留在select.poll、socket.recv、sqlite3.Connection.execute等调用上的协程或线程。
简单验证方法：
- 把关键I/O操作临时替换成await asyncio.sleep(0.1)，如果整体耗时大幅下降，说明原I/O是瓶颈；
- 用psutil.Process().io_counters()对比读写字节数与延迟比值，异常高的IO wait通常指向磁盘或网络慢设备；
- 检查数据库连接池是否耗尽（如SQLAlchemy提示“QueuePool limit reached”），这是典型资源争用信号。
GIL不是万能背锅侠：分清计算型和I/O型任务
CPython的GIL只阻止多线程并行执行Python字节码，但对系统调用（如read/write、SSL握手、numpy底层C运算）会自动释放。因此：
立即学习“Python免费学习笔记（深入）”；
- 纯计算任务（如图像处理、数值迭代）用multiprocessing或concurrent.futures.ProcessPoolExecutor更有效；
- 高并发I/O任务（如API网关、爬虫调度）优先选asyncio，协程切换开销远低于线程；
- 混合场景（如接收请求→解析JSON→调用DB→生成PDF）建议“async I/O + 进程池计算”，用loop.run_in_executor隔离CPU密集段。
共享状态是隐性减速带：锁不是解药，设计才是
用threading.Lock或asyncio.Lock保护全局计数器、缓存字典，看似安全，实则把并发退化为串行。更优路径：
- 用无锁结构：计数用threading.local()做线程局部累加，最后汇总；缓存用asyncio.Queue或按key分片（如hash(key) % 8 → 8个独立dict）；
- 异步任务避免跨协程修改同一对象，改用消息传递（asyncio.Queue.put()）或事件驱动（asyncio.Event.set()）；
- 数据库写入瓶颈？合并小事务为批量操作（executemany）、启用WAL模式、用连接池复用而非频繁open/close。
任务粒度决定并发效率：太细or太粗都拖后腿
协程/线程不是越多越好。一个HTTP请求拆成20个微协程去fetch子资源，可能因调度开销反超单次批量请求。
- 理想I/O任务粒度：单次耗时50–500ms，太短（2s）降低响应灵敏度；
- 用asyncio.wait_for(task, timeout=3.0)主动设界，防止单个慢请求拖垮整批；
- 动态调优：根据实时QPS和P99延迟，用指数移动平均（EMA）算法调整worker数量，例如基于aiomonitor暴露的指标做自适应扩缩容。
不复杂但容易忽略——多数并发性能问题，源于没看清代码在等什么，而不是不会写async或ProcessPool。先观测，再归因，最后替换，比直接重构更省力。
