GIL绕不开的那道墙CPython解释器有一把全局锁叫GIL。同一时刻只有一个线程能执行Python字节码。这意味着多线程在CPU密集型任务上几乎无法并行四个线程跑计算总耗时可能和单线程差不多甚至更慢。多线程的优势在I/O当线程等待网络、磁盘、数据库时GIL会被释放其他线程趁机运行。所以多线程适合“等”多于“算”的场景。多进程则绕开了GIL每个进程有独立的解释器和内存空间能真正并行利用多核。异步则是单线程事件循环靠协程切换没有线程创建和上下文切换的开销。三者的分水岭在于任务是在等还是在算。多线程适合I/O密集但别贪多爬虫抓取网页、批量请求API、读写小文件这些任务大部分时间在等待。多线程能让你在等一个响应时去发下一个请求吞吐量成倍提升。但线程不是越多越好。线程切换有成本共享内存还要加锁。锁用不好死锁、竞态条件接踵而至。一个实用建议I/O密集型任务线程数可以设为CPU核数的几倍但别动辄开几百个。用concurrent.futures.ThreadPoolExecutor管理线程池比手动threading更稳。记住多线程适合“等”不适合“算”。多进程CPU密集的硬解法图像处理、视频转码、科学计算、大规模数据清洗这些任务CPU吃满。多进程让每个核心独立干活性能随核数线性增长。multiprocessing或ProcessPoolExecutor是常用工具。但进程间不共享内存数据传递要序列化开销比线程大。进程启动也慢。所以任务粒度不能太细否则通信成本吃掉并行收益。另外Windows下多进程要放在if __name__ __main__:里否则会无限递归创建进程。多进程适合“算”但要注意数据交换的代价。异步高并发I/O的轻量武器异步编程用async和await在单线程内实现并发。协程切换由程序控制没有线程切换的开销内存占用极低。一个异步程序可以轻松维持上万并发连接。Web服务、API网关、实时通信、高频网络请求异步是首选。但它要求整个调用链都是异步的一个同步阻塞调用就能卡死事件循环。异步生态也有局限很多库还不支持。异步适合“等”且“等得密集”的场景代码复杂度比多线程高调试也更难。用得好是利器用不好是迷宫。怎么选看任务也看生态判断标准可以浓缩成一句话CPU密集用多进程I/O密集用多线程或异步高并发I/O优先异步。如果任务混合了计算和I/O可以组合使用异步处理网络请求把计算结果丢给进程池。Web框架里FastAPI用异步Django的ORM多数同步选择要跟着生态走。没有银弹只有权衡。先分析瓶颈在哪里是CPU跑满还是等待太长用cProfile、py-spy定位再决定用哪种并发模型。别为了并发而并发简单场景同步代码反而最可靠。选对了工具Python的并发能力远超你想象。
