asyncio.condition 不能直接 await，因其非协程而是同步原语，须用 wait()/notify() 等方法且必须配合 asyncio.lock；需在 async with 或 acquire 后操作，并用 while 循环防虚假唤醒。
asyncio.Condition 为什么不能直接 await
直接对 asyncio.Condition 对象执行 await cond 会报 TypeError: object Condition can't be used in 'await' expression。它本身不是协程，而是一个协程同步原语，必须配合其方法使用——比如 wait()、notify()、notify_all()，且所有操作都必须在已获取关联锁的前提下进行。
常见错误是忘了先调用 acquire() 或用了普通 threading.Lock 做参数；asyncio.Condition 要求传入的是 asyncio.Lock（或 asyncio.Semaphore），否则运行时报 RuntimeError: expected an asyncio.Lock or asyncio.Semaphore。
- 必须显式创建并传入
asyncio.Lock()：cond = asyncio.Condition(asyncio.Lock()) - 所有
wait()/notify()操作前，需用async with cond:或手动await cond.acquire()+cond.release() -
wait()会自动释放锁，并在被唤醒后重新获取锁；但notify()不会释放锁，需自行控制临界区范围
如何用 wait() 等待某个条件成立
wait() 的本质是“挂起当前协程，直到其他协程调用 notify() 或 notify_all()”，但它不检查任何业务逻辑——你得自己在 while 循环里判断状态是否真正满足，否则可能虚假唤醒（spurious wakeup）。
典型模式是：进入 async with cond: 后，用 while not some_condition: 包裹 await cond.wait()。比如等待一个共享变量 data_ready 变为 True：
data_ready = False
<p>async def waiter():
async with cond:
while not data_ready:
await cond.wait() # 挂起，等 notify
print("got data!")</p><p>async def setter():
global data_ready
await asyncio.sleep(1)
async with cond:
data_ready = True
cond.notify() # 唤醒一个 waiter</p>
- 不能写成
if not data_ready: await cond.wait()—— 缺少循环，无法应对唤醒后条件仍不成立的情况 -
wait()返回后，协程已重新持有锁，可安全读取共享状态 - 若多个 waiter 在等同一条件，只用
notify()会唤醒其中一个；需全部唤醒时改用notify_all()
notify() 和 notify_all() 的唤醒时机与竞态问题
notify() 和 notify_all() 不会立即切换协程，只是将等待队列中的协程标记为“就绪”；实际调度取决于事件循环。更关键的是：如果 notify() 发生在 wait() 之前（即“丢失通知”），协程会永远挂起。
避免丢失通知的唯一可靠方式是：把状态变更和 notify() 放在同一个 async with cond: 块中，并确保 waiter 先进入等待再让 notifier 修改状态。例如：
# ❌ 危险：notify 可能发生在 waiter 进入 wait() 之前
async def unsafe_notifier():
await asyncio.sleep(0.1)
async with cond:
data_ready = True
cond.notify()
<h1>✅ 安全：状态变更和 notify 在同一临界区内，且 waiter 已持锁等待</h1><p>async def safe_notifier():
async with cond:
data_ready = True
cond.notify()</p>
- 不要依赖 sleep() 控制执行顺序——异步环境下不可靠
- notify 系列方法必须在持有锁时调用，否则抛
RuntimeError: notify on un-acquired lock - 即使没有 waiter 在等，
notify()也合法，不会报错
Condition 和 asyncio.Event 的核心区别在哪
asyncio.Event 更轻量，适合“一次性信号”场景（如启动完成、关闭通知）；Condition 则用于需要“等待某个可变状态满足”的复杂同步，比如生产者-消费者中等待缓冲区非空/非满。
两者最大差异在于：Event 的 set() 是幂等的，多次调用等价于一次；而 Condition 的 notify() 是瞬时的，没有等待者就失效。另外，Event 不需要显式锁，内部已封装；Condition 必须配锁，且允许你在锁保护下做任意状态检查和修改。
- 只发一次信号 → 用
asyncio.Event，简单直接 - 要等
queue.qsize() > 0或buffer_full == False这类动态条件 → 必须用asyncio.Condition - 别试图用
Event替代Condition做多条件等待——它不支持wait_for外部谓词，也没有内置重入保护
最易被忽略的一点：Condition 的等待队列是 FIFO，但事件循环调度本身不保证绝对顺序；若需严格顺序唤醒，得在应用层加序号或状态标记，不能只靠 notify 调用次序。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
