queue.Queue线程安全但不自动协调多生产者多消费者同步，需手动设计终止协议（如哨兵值）、配对task_done()、避免依赖qsize()等不可靠方法。
为什么直接用 queue.Queue 不能自动解决多生产者多消费者同步问题
queue.Queue 本身是线程安全的，但它只保证入队/出队操作原子，不负责业务逻辑的协调。比如多个消费者同时调用 get()，谁拿到任务、是否该退出、如何通知全部消费者停止，这些都得你手动控制。常见错误是消费者在 queue.Empty 异常后盲目 continue，导致 CPU 空转；或生产者提前结束却没发“结束信号”，消费者永久阻塞在 get() 上。
关键点在于：必须约定一种终止协议，最常用的是往队列里放特殊哨兵值（如 None），每个消费者收到就退出。
- 不要依赖
q.qsize()判断是否为空——它不可靠，多线程下返回的值可能瞬间失效 - 避免用
q.get_nowait()轮询；改用q.get(timeout=1)配合异常捕获，减少无效调度 - 生产者全部结束后，必须发送与消费者数量相等的哨兵，否则会有消费者永远等不到退出信号
如何正确启动多生产者并安全结束
生产者通常是 I/O 密集型任务（如读文件、发 HTTP 请求），适合用 threading.Thread 启动。重点不是“怎么发数据”，而是“怎么知道所有生产者真结束了”。不要让主线程 sleep 等待，而应调用 t.join() 显式等待每个生产者线程完成。
- 每个生产者函数末尾必须调用
q.task_done()—— 这不是可选的，它影响q.join()的行为 - 如果生产者抛异常退出，要确保仍能向队列发送哨兵，否则消费者会卡住；可用
try/finally包裹 - 生产者数量不确定时（比如动态创建），建议用
concurrent.futures.ThreadPoolExecutor管理，更易等待完成
def producer(q, items):
try:
for item in items:
q.put(item)
finally:
q.put(None) # 发送一个哨兵
消费者如何避免假死和重复消费
消费者循环里最典型的坑是把 q.get() 放在 try 外面，导致一旦拿到 None 就退出，但没调用 q.task_done()，后续 q.join() 永远不会返回。另一个问题是多个消费者同时 get 到同一个哨兵，造成部分消费者误判退出。
立即学习“Python免费学习笔记（深入）”；
- 每次
q.get()后，无论内容是什么，都要配对调用q.task_done() - 检查哨兵必须在
q.get()之后立即做，且用is判断（item is None），避免和业务中合法的None值混淆 - 如果消费者需要处理结果并写回队列（比如二级消费），注意别把哨兵也转发出去，否则下游消费者会提前退出
def consumer(q, worker_id):
while True:
item = q.get()
if item is None: # 哨兵，准备退出
q.task_done()
break
# 处理 item...
q.task_done()
什么时候该换 multiprocessing.Queue 或 asyncio.Queue
纯 CPU 密集型任务用 threading + queue.Queue 效果差，因为 GIL 限制了并发执行。此时若需真正并行，得切到 multiprocessing，但要注意：multiprocessing.Queue 不支持 join() 和 task_done()，得用 mp.Barrier 或进程间信号量协调；而 asyncio.Queue 适用于协程场景，但要求整个调用链都是 async/await，混用同步阻塞 IO 会拖垮性能。
- IO 密集、任务轻量、线程数 ≤ 10：坚持用
threading+queue.Queue - CPU 密集、需利用多核：换
multiprocessing，放弃task_done，改用q.empty()+ 超时 + 主进程计数来判断结束 - 高并发网络请求、大量等待：用
asyncio.Queue，但所有 IO 必须是异步库（如aiohttp）
哨兵机制看着土，却是跨线程/进程最稳妥的终止方式。别指望队列自己感知“生产者没了”，它永远在等下一个 put。
