直接用 BoundedSemaphore 控制 queue.Queue 容量易出错，因其加锁粒度与队列内部锁不一致，导致竞态条件；正确做法是直接使用 queue.Queue(maxsize=N) 自带的线程安全容量控制机制。
为什么直接用 BoundedSemaphore 控制队列容量容易出错
很多人以为给 queue.Queue 加个 BoundedSemaphore 就能“双重保险”控制容量，结果发现队列仍可能超限或阻塞异常。根本原因是：BoundedSemaphore 和 queue.Queue 的加锁粒度不一致——put() 和 get() 内部已有自己的锁，而你手动 acquire/release 的信号量无法与之原子同步。比如在 put() 判断队列未满后、真正插入前被抢占，就可能突破上限。
正确做法：用 queue.Queue(maxsize=N) 自带的阻塞机制
queue.Queue 本身已线程安全且内置容量控制，不需要额外套 BoundedSemaphore。它的 put() 在满时默认阻塞，也可设 block=False 抛 queue.Full，get() 同理。
- 初始化时直接传
maxsize：q = queue.Queue(maxsize=10) - 写入时显式处理满状态：
try: q.put(item, block=False) except queue.Full: print("队列已满") - 读取时注意空队列：
try: item = q.get(block=False) except queue.Empty: ... - 避免混用
q.qsize()做判断——它在多线程下返回的是瞬时快照，不可靠
真需要自定义容量逻辑时，如何安全封装 BoundedSemaphore
仅当你要实现非标准行为（如“允许临时超限但记录告警”“按优先级抢占槽位”）才考虑手动管理信号量。此时必须确保信号量操作与队列操作处于同一临界区：
- 用
threading.Lock包裹整个put/get流程，再在锁内操作BoundedSemaphore - 不要单独对信号量调用
acquire()后再调用q.put()——中间有竞态窗口 - 示例关键片段：
self._lock = threading.Lock() self._sem = threading.BoundedSemaphore(10) def safe_put(self, item): with self._lock: self._sem.acquire() # 必须在锁内获取 try: self._queue.put(item) # 真正入队 except Exception: self._sem.release() # 失败要归还许可 raise
性能与兼容性提醒
queue.Queue 底层用的是 collections.deque + threading.Condition，比手写信号量+列表更轻量、更可靠。Python 3.7+ 中 queue 还优化了唤醒逻辑，减少虚假唤醒。而 BoundedSemaphore 是基于底层系统信号量或条件变量模拟，在高并发下争用开销略大。除非业务逻辑明确要求信号量语义（比如跨多个不同资源共享同一计数器），否则别绕路。
立即学习“Python免费学习笔记（深入）”；
最常被忽略的一点：queue.Queue 的 maxsize 设为 0 表示无限容量，不是“不限制”，这点和 BoundedSemaphore(0) 完全不同——后者根本无法 acquire，极易卡死。
