deque比list更适合高并发队列操作，因其两端增删为O(1)，而list头部操作为O(n)，可减少锁竞争、提升吞吐；但deque本身线程不安全，需配合queue.Queue等线程安全封装使用。
deque 为什么比 list 更适合高并发的队列操作
因为 deque 的两端插入和删除是 O(1) 时间复杂度，而 list 在头部做 insert(0, x) 或 pop(0) 是 O(n) —— 每次都要移动后面所有元素。在多线程或异步任务频繁 push/pop 的场景下，这点差异会直接反映为锁竞争时间变长、吞吐下降。
常见错误现象：queue.Queue 虽线程安全，但底层用的是 deque + 锁；有人却自己用 list 加 threading.Lock 模拟队列，结果锁住的时间远超必要——本质是选错了底层容器。
- 使用场景：任务分发器、日志缓冲区、WebSocket 消息广播队列
-
deque的maxlen参数能自动丢弃旧项，适合限流或滑动窗口，list得手动切片，容易漏删或误删 - 注意：
deque不支持随机索引加速（d[10000]是 O(n)），别把它当 list 用
多线程中直接用 deque 是否线程安全
不安全。Python 的 deque 本身不是原子操作容器，多个线程同时调用 append() 和 popleft() 可能导致数据丢失或 IndexError: pop from empty deque。
正确做法不是加锁封装，而是优先用标准库的线程安全队列：
立即学习“Python免费学习笔记（深入）”；
- 普通生产者-消费者：用
queue.Queue（基于deque+threading.Condition） - 需要非阻塞或超时：用
queue.SimpleQueue（Python 3.7+，更轻量，但无 maxsize 和 task_done） - 纯内存高速通道且能接受少量竞争：可对
deque加细粒度锁，但必须锁住成对操作，比如with lock: d.append(x); d.popleft()不能只锁一半
asyncio 中用 deque 还是 asyncio.Queue
必须用 asyncio.Queue。虽然 deque 在协程里不会被抢占，但它不感知 event loop，无法挂起等待；直接在 await 函数里操作 deque 会导致“假并发”——看起来没报错，实际是同步串行执行。
典型错误现象：用 deque 存待处理请求，然后在 async for 里循环 popleft()，结果所有协程都卡在空 deque 上 busy-wait，CPU 拉满，event loop 响应变慢。
-
asyncio.Queue支持put_nowait()/get_nowait()（类似deque），也支持await put()/await get()（自动挂起） - 如果真要裸用
deque（比如做本地缓存），确保只在单个协程内操作，或用asyncio.Lock包裹，但性能不如原生 Queue -
asyncio.Queue的maxsize是软限制，满时put()会 await，这点deque完全不提供
deque 的内存开销和 GC 表现
deque 内部用双向链表块（block）管理元素，每块默认存 64 个对象指针。这意味着：存 1 个元素也要占一块内存；存 1000 个元素大概用 16 块，但不会像 list 那样预分配空间导致浪费。
容易被忽略的地方：
- 大量短生命周期
deque（比如每个 HTTP 请求建一个），会触发频繁的小块内存分配，GC 压力比list大 -
deque.clear()不释放已分配的 block，只是清空引用；反复 clear + append 可能导致内存不回落 - 若确定大小固定且只从一端操作，用
list+append()/pop()反而更省内存、更快（避免链表跳转）
高并发服务上线前，建议用 tracemalloc 对比两种结构的峰值内存和 block 分配次数，而不是只看文档说的“deque 更快”。
