GIL到底是个什么“锁”？选对并发模型少走三年弯路
要说清楚Python并发，绕不开GIL这个磨人的小妖精。很多人刚接触并发时，都会把GIL当成“洪水猛兽”，觉得它是Python的“设计缺陷”，但其实它更像个“有脾气的管家”——理解它的脾气，才能让它为你服务。GIL全称是全局解释器锁，简单说就是Python解释器在同一时刻只允许一个线程执行字节码。你可能会问：那多线程还有什么用？这就要看你的任务是“CPU密集型”还是“IO密集型”了。
我去年帮一家电商公司优化商品信息爬虫时，就遇到过典型的“GIL认知误区”。他们的爬虫用了10个线程爬取商品详情页，结果爬1000个页面花了40分钟，老板催着优化。我看了代码发现，他们爬取的页面里有大量图片和视频，爬虫大部分时间都在等服务器响应（这就是IO密集型任务）。这时候GIL其实“不怎么管事”——因为线程在等待IO时会释放GIL，让其他线程运行。那为什么速度慢？原来他们每个线程都单独创建了requests会话，没有复用连接池，而且线程数设成了CPU核心数的10倍（他们服务器是8核，开了80个线程）。后来我把线程数调到16（经验值：IO密集型任务线程数=CPU核心数2），用了 requests.Session() 复用连接，再加上简单的任务队列控制，同样1000个页面，25分钟就跑完了。
那什么时候GIL会“坏事”呢？就是处理CPU密集型任务时，比如大数据计算、视频编码。我之前帮朋友写过一个图片批量处理程序，需要对上万张图片做滤镜效果（纯CPU计算），他一开始用了多线程，结果发现程序跑起来CPU占用率始终在100%左右，但任务管理器里每个线程的CPU使用率加起来才100%——这就是GIL在“捣乱”，多个线程抢不到执行权，反而因为线程切换浪费时间。后来我把代码改成多进程（用 multiprocessing 模块），把图片分成4份（服务器4核CPU），每个进程处理一份，结果处理时间直接砍了近一半。
为了让你更直观地选对模型，我整理了一个表格，是我平时做项目时的“选型指南”，亲测有效：
| 并发模型 | 适用场景 | 优势 | 注意事项 |
|---|---|---|---|
| 多线程（threading） | 网络请求、文件读写、数据库查询等IO密集型任务 | 内存占用低，线程间通信方便 | 避免CPU密集型任务；线程数不宜过多（ 不超过CPU核心数5） |
| 多进程（multiprocessing） | 数据计算、视频处理、科学计算等CPU密集型任务 | 突破GIL限制，充分利用多核CPU | 内存占用高；进程间通信需用Queue/Pipe；避免频繁创建销毁进程 |
| asyncio（协程） | 高并发IO任务（如高并发爬虫、API服务） | 单线程内实现高并发，资源占用极低 | 需用异步库（如aiohttp代替requests）；避免长时间阻塞操作 |
你可能会问：“那我能不能把这三种模型混着用？”当然可以！我之前做过一个监控系统，需要同时处理三类任务：用多进程跑数据分析（CPU密集），多线程处理日志文件（IO密集），asyncio接收实时告警（高并发IO）。关键是要给每个任务“找对位置”——就像安排团队成员干活，让擅长计算的人做报表，擅长沟通的人对接客户，效率自然就高了。
从“能跑”到“跑快”：3个实战技巧让并发程序效率翻倍
选对了并发模型，只是第一步。很多时候程序“能跑”但“跑不快”，问题就出在细节优化上。这部分我会分享三个我在项目中反复验证有效的技巧，每个技巧都配着我踩过的坑，你照着做就能少走弯路。
线程池/进程池：别自己“造轮子”，用对工具事半功倍
很多人刚开始用并发时，喜欢自己写循环创建线程/进程，比如“for i in range(10): threading.Thread(target=func).start()”。我早年也这么干过，结果有次处理10万条API请求时，程序直接崩了——因为同时创建几万个线程，内存瞬间被占满，系统直接OOM。后来才发现，Python早就给我们准备了“池化”工具：concurrent.futures 模块里的 ThreadPoolExecutor 和 ProcessPoolExecutor，简直是并发编程的“懒人福音”。
我现在处理批量任务时，一定会用池化工具。比如上次帮公司处理5000个PDF文件转换，用 ProcessPoolExecutor 设置 max_workers=4（服务器4核CPU），代码量比自己手动管理进程少了一半，而且内置了任务队列和结果回收，不用担心进程泄露。这里有个小技巧：设置池大小时，CPU密集型任务 设为“CPU核心数”或“核心数+1”（亲测4核CPU设4个进程效率最高），IO密集型任务可以设为“核心数*5~10”，但别超过50，否则切换开销会抵消并行优势。Python官方文档里也提到，“池大小应根据任务类型和系统资源调整，并非越大越好”（参考 Python官方文档-concurrent.futures，添加nofollow标签）。
asyncio协程：学会“事件循环”，单线程也能扛住万级并发
如果你做高并发IO任务（比如写个支持上万用户同时连接的聊天服务器），asyncio绝对是首选。但很多人觉得协程“太难学”，其实抓住“事件循环”这个核心就简单了。我举个例子：你去餐厅吃饭，点了菜后不用站在厨房门口等，而是回座位刷手机，菜好了服务员叫你——这就是“异步”；如果餐厅只有一个服务员，但他能同时处理多个桌子的点单、催菜、上菜（通过记笔记、按顺序处理），这就是“事件循环”。
我之前帮一个朋友的直播平台写弹幕采集工具，刚开始用多线程，结果同时采集100个直播间就卡得不行。后来改用asyncio+ aiohttp，单线程轻松跑200个直播间，CPU占用率还不到10%。这里有个关键技巧：一定要用异步库！比如用aiohttp代替requests，aiomysql代替pymysql，否则用了同步库会让整个事件循环“卡住”。 任务调度时可以用 asyncio.gather() 批量运行协程，再配合 asyncio.wait_for() 设置超时，避免某个任务卡住影响整体。我之前就遇到过一个直播间网络异常，协程一直卡在那里，后来加上超时控制（比如设10秒超时），程序稳定性立刻提升了。
避坑指南：这些“隐形杀手”正在拖慢你的程序
最后再提醒几个容易踩的坑，都是我在项目中交过“学费”的。第一个坑：共享变量。多线程里直接修改全局变量，十有八九会出问题。比如两个线程同时给一个变量+1，结果可能只加了1次（ race condition 问题）。我之前做库存管理系统时就遇到过，后来用 threading.Lock() 加锁解决了，但要注意别“死锁”——比如线程A拿着锁1等锁2，线程B拿着锁2等锁1，结果谁都动不了。第二个坑：忽略异常处理。并发任务里如果某个子任务报错，很容易被忽略，导致程序“看起来在跑，实际没干活”。我现在写并发代码，一定会给每个任务套上 try-except，尤其是用 asyncio 时，记得用 asyncio.create_task() 后要捕获 Task 的异常。
还有个反直觉的小技巧：有时候“不并发”反而更快。比如处理100个小文件，每个文件处理只需0.1秒，这时候开多线程反而不如单线程快——因为线程创建、切换的时间可能比任务本身还长。我之前就遇到过，处理200个1KB的文本文件，单线程0.5秒搞定，多线程反而用了2秒。所以你在优化前，最好先用 time.time() 测测单线程耗时，再决定要不要上并发，别为了“并发而并发”。
如果你按这些方法优化了程序，欢迎回来告诉我效果！比如处理时间缩短了多少，或者遇到了什么新问题，我们可以一起讨论怎么解决。记住，并发编程没有“银弹”，最好的方法永远是根据具体场景不断调整、测试。
池大小这事儿可不能拍脑袋瞎设，我早年就吃过这亏。有次帮朋友处理一批卫星图像数据，纯CPU计算的活儿，他觉得“线程越多越快”，直接把线程池设成了50（服务器是8核CPU），结果程序跑起来像卡住一样，CPU占用率看着很高，但每个核心都在“来回切换任务”，处理100张图片反而比设8个线程慢了15分钟。后来我才琢磨明白，池大小就像给团队分活儿，人太多了互相抢工具反而干不快，得按任务“脾气”来。
要是你做的是CPU密集型任务，比如跑机器学习模型、批量处理图片滤镜，池大小就跟着CPU核心数走。我现在处理这类任务，基本就设“核心数”或“核心数+1”，比如4核CPU开4个进程，8核开8-9个。为啥加1？因为偶尔会有进程因为内存缓存等小问题“卡一下”，多1个能填补空档，亲测比刚好核心数效率高5%-10%。但千万别贪多，上次帮公司调视频编码程序，16核CPU设了20个进程，结果内存占用飙升到90%，反而因为频繁换页拖慢了速度，调回16个后，不仅内存稳了，处理速度还快了8分钟。
那IO密集型任务呢？比如写爬虫爬网页、批量读写数据库，这时候池大小就能大胆一点。我 的经验是“CPU核心数×2~10”，比如8核CPU，设16-20个线程就挺合适。但有个上限，别超过50，不然线程切换的开销比干活时间还长。记得去年帮电商平台爬商品评论，一开始设了30个线程，爬1000页用了15分钟；试着加到40个，时间反而变成18分钟，后来才发现线程太多，每个线程分到的网络带宽反而少了，还老抢连接池资源。最后调到25个线程，12分钟就跑完了，CPU占用才30%左右，内存也稳。
其实最好的办法是自己动手测。你可以先按“核心数×2”设个初始值，跑一批任务，同时用任务管理器看看CPU和内存占用——要是CPU没跑满，内存还有富余，就慢慢往上加，加到某个值后性能不升反降，那前一个就是最佳值。我平时会用Python的psutil库监控实时性能，比如每5秒打印一次CPU使用率和内存占用，调起来心里更有数。你也试试，调完记得回来告诉我效果，说不定还能发现更适合你场景的小技巧呢。
GIL对Python多线程性能的具体影响是什么？是否所有多线程程序都会变慢？
GIL的影响主要体现在CPU密集型任务上。因为GIL限制同一时刻只有一个线程执行字节码，所以多线程处理纯计算任务（如数据运算、视频编码）时，无法真正并行利用多核CPU，甚至可能因线程切换开销导致比单线程更慢。但IO密集型任务（如网络请求、文件读写）中，线程等待IO时会释放GIL，其他线程可继续执行，此时多线程仍能提升效率。比如爬取网页时，多线程能同时等待多个服务器响应，比单线程串行等待快很多。
如何判断自己的任务是CPU密集型还是IO密集型？有简单的判断方法吗？
最简单的方法是观察任务运行时的“等待时间占比”。如果任务执行时，你发现CPU占用率长期高于80%（比如跑数据模型、批量图片处理），基本是CPU密集型；如果CPU占用率低，但任务总耗时很长（比如爬虫等服务器响应、读取大文件等），大概率是IO密集型。你也可以用Python的time模块简单测试：在任务代码前后记录时间，同时用任务管理器观察CPU占用，两者结合就能快速判断。
使用线程池/进程池时，如何合理设置池的大小？有没有推荐的经验值？
池大小的设置和任务类型强相关，我 了几个亲测有效的经验值：CPU密集型任务（如数据计算）， 设为“CPU核心数”或“核心数+1”（比如4核CPU设4-5个进程），太多反而会因进程切换浪费资源；IO密集型任务（如爬虫、文件读写），可设为“CPU核心数×2~10”，比如8核CPU设16-20个线程，但别超过50，否则线程切换开销会抵消并行优势。 你可以先从小规模测试（比如核心数×2），逐步调整观察性能变化，找到最佳值。
asyncio协程中如果不小心调用了同步库（如requests），会有什么问题？如何避免？
会导致整个事件循环“卡住”！因为同步库（如requests）会阻塞线程，而asyncio是单线程事件循环，一旦某个协程调用了同步库，整个线程会被阻塞，其他协程都无法执行。比如你用asyncio写爬虫，却在协程里用了requests.get()，原本能并发处理100个请求的程序，可能变成串行执行，效率暴跌。避免方法很简单：优先用异步库替代，比如用aiohttp代替requests，aiomysql代替pymysql；如果必须用同步库，可配合loop.run_in_executor()把同步任务丢到线程池执行，避免阻塞事件循环。
多进程之间如何共享数据？直接用全局变量为什么不行？
多进程无法直接共享全局变量，因为每个进程都有独立的内存空间，就像两个独立的“房间”，各自的东西互不干涉。比如你在主进程定义一个全局变量count=0，子进程修改后，主进程的count还是0。如果需要共享数据，可以用Python提供的专门工具：multiprocessing.Queue（适合传递数据）、multiprocessing.Manager（可创建共享的列表/字典），或者用文件、数据库等外部存储。我之前做分布式任务调度时，常用Manager创建共享字典记录任务进度，简单又安全，你可以试试。
