asyncio协程中禁用threading.Lock，因其会阻塞整个OS线程导致事件循环停摆；应改用asyncio.Lock（需同协程acquire/release）或Semaphore限流，I/O操作必须移出锁区。
asyncio协程里调用threading.Lock会卡死事件循环
因为threading.Lock是操作系统级同步原语，它一阻塞就直接挂起整个OS线程——而asyncio默认只在一个线程里跑事件循环。一旦某个协程在with threading.Lock()里等锁，线程就停了，事件循环跟着停摆，其他协程全被冻住，包括那个本该释放锁的协程。
常见错误现象：await asyncio.create_task(...)之后程序彻底不动、CPU几乎为0、超时后抛asyncio.TimeoutError；但没有任何报错或日志提示锁问题。
- 不要在
async def函数里用threading.Lock、threading.RLock或任何threading.*同步对象 - 如果必须保护共享状态，改用
asyncio.Lock（仅限同一事件循环内） - 若涉及跨线程共享数据（比如后台线程更新全局变量），用
threading.Lock保护，但所有访问都得在同步上下文中完成，不能混进await链
asyncio.Lock跨协程release会静默失败
asyncio.Lock不是“谁拿到谁放”的句柄，它内部绑定的是当前持有锁的Task对象。你在协程A里await lock.acquire()，然后在协程B里调lock.release()，这个调用不会报错，也不会生效——锁永远不释放，后续所有await lock.acquire()都会无限挂起。
使用场景：常见于想把“加锁→I/O→解锁”拆成多个任务，比如主协程拿锁，丢个asyncio.create_task()去发HTTP请求，再让子任务负责解锁。
立即学习“Python免费学习笔记（深入）”；
- 所有
acquire()和release()必须在同一个async def函数内配对 - 优先用
async with lock:，它会在退出时自动释放，异常也不会漏 - 别在
async with lock:块里启动新Task，更别让它碰这把锁
混用时I/O操作拖长临界区引发饥饿
很多人以为“锁住一段代码就行”，于是把await httpx.AsyncClient().get()或await aiomysql.execute()塞进async with asyncio.Lock():里。结果是：锁一直占着，其他协程全卡在acquire()上干等，而你还在等网络响应——本质是把内存互斥变成了串行I/O，吞吐量暴跌。
性能影响：临界区越长，协程并发度越低；极端情况下，哪怕只有两个协程，也会退化成纯顺序执行。
- 只锁纯内存操作：更新字典、递增计数器、切换标志位
- I/O操作一律移出
async with lock:块 - 真要限流调API，用
asyncio.Semaphore(1)，语义明确且不会误导人
threading.Lock在多线程中交叉加锁引发循环等待
当多个线程以不同顺序获取多个threading.Lock时，就可能触发经典死锁：线程A拿了lock_a等lock_b，线程B拿了lock_b等lock_a。Python解释器不会检测或中断这种状态，程序就僵在那里。
容易踩的坑：银行转账、资源分配、对象间双向调用这类逻辑，极易写出交叉加锁路径。
- 给所有锁定义唯一ID，按升序统一加锁顺序（例如始终先
lock_a再lock_b） - 用
threading.RLock替代threading.Lock可避免同一线程重入死锁，但解决不了跨线程循环等待 - 考虑用更高层抽象，比如
queue.Queue代替手动锁+共享变量
