Python的queue.Queue不适合高并发无锁场景，因其内部重度依赖threading.Lock，所有操作均需竞争同一把锁，导致吞吐下降5–10倍且不满足lock-free定义。
为什么 Python 的 queue.Queue 不适合高并发无锁场景
因为 queue.Queue 内部重度依赖 threading.Lock，所有 put() 和 get() 操作都会阻塞并竞争同一把锁。在数千级线程/协程频繁进出队列时，锁争用会成为性能瓶颈，实测吞吐可能比无锁结构低 5–10 倍。
更关键的是：它不是无锁（lock-free）的——不满足等待无关（wait-free）或无锁（lock-free）的严格定义，无法保证单个线程总能在有限步内完成操作。
常见错误现象：Queue.put_nowait() 看似“非阻塞”，但底层仍需获取锁；压测中 CPU 花费大量时间在 acquire()/release() 上，perf record 显示 pthread_mutex_lock 占比超 40%。
用 collections.deque + threading.Atomic 模拟无锁入队
Python 没有原生原子指针或 CAS 指令暴露给用户，但 collections.deque 的左端/右端操作（append() / popleft()）在 CPython 中是原子的（GIL 保证其不会被中断），且不涉及内存重分配（内部是双向链表块）。这是唯一可信赖的“准无锁”基础。
立即学习“Python免费学习笔记（深入）”；
- 只允许单生产者 + 单消费者（SPSC）模式下直接使用
deque.append()和deque.popleft()—— 这时无需任何锁，也无竞态 - 多生产者（MPSC）必须引入原子计数器协调写位置，CPython 中可用
threading.atomic（Python 3.12+）或ctypes调用__atomic_fetch_add（Linux） - 避免用
deque.appendleft()或deque.pop()，它们在某些长度下会触发内部块迁移，破坏原子性 - 示例（SPSC 安全用法）：
from collections import deque q = deque() # 生产者线程中： q.append(item) # 原子 # 消费者线程中： item = q.popleft() # 原子（仅当 len(q) > 0）
用 asyncio.Queue 替代线程队列做协程级“逻辑无锁”
虽然 asyncio.Queue 内部用了 asyncio.Lock，但它不阻塞 OS 线程，只挂起协程，上下文切换开销极低。在 asyncio 生态中，它是事实上的高并发队列首选。
关键点在于：它把“锁等待”转化为 await 挂起，调度器自动切走，CPU 不空转。压测显示，在 10k 协程持续 put()/get() 时，吞吐可达 50w ops/s，远超线程版 Queue。
-
asyncio.Queue(maxsize=0)表示无限容量，避免Full异常打断流程 - 不要混用线程和协程访问同一个
asyncio.Queue实例 —— 它不是线程安全的 - 若需跨线程投递任务到事件循环，用
loop.call_soon_threadsafe(queue.put_nowait, item) - 错误用法：
queue.get()（同步调用）会阻塞整个线程，必须用await queue.get()
真正无锁？Python 里只能靠外部库或降级到 C 扩展
纯 Python 无法实现符合学术定义的 lock-free 队列（如 Michael-Scott 算法），因为缺少原子读-改-写（CAS）、内存序控制（memory ordering）和无锁内存分配器支持。
可行路径只有两条：
- 用
cython或cffi封装已验证的 C 无锁队列（如liblfds或moodycamel::ConcurrentQueue），暴露为 Python 接口；注意 GIL 释放与重入问题 - 用
numba.jit(nopython=True)编译带原子操作的队列逻辑（仅限 Numba 支持的平台，且目前不支持 CAS） - 接受现实：对绝大多数 Python 服务，
asyncio.Queue+ 正确的协程调度，比硬上无锁 C 扩展更稳定、更易维护
最容易被忽略的一点：所谓“无锁”，不等于“无等待”或“无竞争”。即使用了 CAS，缓存行伪共享（false sharing）、内存屏障缺失、GC 干扰都可能导致实际延迟毛刺。先测再换，别为概念而设计。
