queue.Queue是Python多线程生产者-消费者问题最直接可靠方案，自带线程安全；应依赖put/get的阻塞行为而非qsize()/empty()判断，正确使用block参数、哨兵值和task_done()确保安全终止与任务跟踪。
queue.Queue 是解决 Python 多线程下生产者-消费者问题最直接、最可靠的方式——它自带线程安全，不用手动加锁，也不用担心竞态条件。只要你用对了 put() 和 get() 的阻塞行为，模型就能稳定运行。
为什么不能靠 qsize() 或 empty() 控制逻辑
很多初学者会写类似 if not q.empty(): item = q.get() 这样的代码，结果偶发 queue.Empty 异常。这是因为 qsize() 和 empty() 返回的是“瞬时快照”，调用完立刻可能被其他线程改写。多线程环境下，它们的返回值不可用于分支判断。
- 正确做法是依赖
get(block=True)的天然阻塞：队列空时自动等待，无需轮询 - 若想非阻塞尝试获取，用
get(block=False)并捕获queue.Empty，而不是先查状态再取 -
maxsize设为正整数后，put(block=True)在满时也会阻塞，这正是背压（backpressure）机制的核心
put() 和 get() 的 block 参数怎么选
默认 block=True 是最稳妥的选择，尤其对新手。它让线程在资源不可用时安静等待，而不是忙等或崩溃。
- 生产者写
q.put(item)：若队列已满（且设了maxsize），线程挂起，直到有空位 —— 防止内存无限增长 - 消费者写
item = q.get()：若队列为空，线程挂起，直到有新数据 —— 避免空转和异常 - 只有在明确需要“立即失败”语义时才设
block=False，比如做探测性操作，且必须配try/except -
timeout可选，但慎用：超时后抛出异常，需额外处理路径，反而增加复杂度
如何安全终止多个消费者线程
没有“自然结束”的信号机制，消费者容易卡死在 q.get() 上。常见错误是用全局 flag + 轮询，既低效又破坏阻塞优势。
- 推荐做法：生产者结束后向队列放入与消费者数量相等的哨兵值（如
None），每个消费者取到哨兵就退出 - 更健壮的做法：用
q.join()+task_done()，但前提是所有消费者都调用task_done()—— 这要求你把“处理完成”作为明确步骤，而非仅取数据 - 注意：哨兵必须在所有真实数据之后放入，且每个消费者只消费一个哨兵；否则可能漏数据或提前退出
多消费者场景下，task_done() 容易被忽略的细节
如果你用了 q.join() 等待所有任务完成，却忘了在消费者里调用 task_done()，主线程就会永远卡住。
立即学习“Python免费学习笔记（深入）”；
-
task_done()必须在消费者成功处理完一个get()返回的项后调用，不是在get()之后立刻调用 - 如果处理过程可能失败（比如网络请求异常），应在
try/except的finally块中调用task_done()，否则计数会丢失 -
q.unfinished_tasks是内部计数器，不可读写，只能靠task_done()递减 —— 它不反映队列长度，只反映“已取未完成”的任务数
queue.Queue 的阻塞契约：它不保证“立刻响应”，但保证“绝不丢数据、绝不坏状态”。只要放弃轮询、信任阻塞、正确传递终止信号，剩下的就是模式复用。 
