直接用collections.deque做环形缓冲区需小心maxlen参数，因其仅在显式设置后才启用自动丢弃旧元素的环形语义；未设maxlen则为普通双端队列，不具固定长度特性，且混用pop/remove或非原子判断易引发竞态与逻辑错误。
为什么直接用 collections.deque 做环形缓冲区要小心 maxlen
很多人一想到“固定长度、自动丢弃旧数据”的环形缓冲，立刻选 deque，但默认构造不设 maxlen 就等于普通双端队列，不会自动裁剪。只有显式传入 maxlen 参数，deque 才在 append() 或 appendleft() 时自动弹出对端元素——这才是环形语义的核心机制。
常见错误是先创建空 deque，再手动 pop() 控制长度，这不仅破坏原子性（多线程下易出错），还让逻辑分散、可读性差。
-
deque([], maxlen=5)：初始化即锁定容量，后续所有append()都自动维护环形行为 - 一旦设了
maxlen，就不能再通过append()超过该长度；试图extend()超长列表会截断，但行为不如单次append()可预测 -
maxlen=None（默认）时，deque永远增长，完全不具备环形特性
如何用 deque 实现带索引访问的环形缓冲
原生 deque 不支持 buffer[i] 随机访问，但环形缓冲常需读取“倒数第 N 个”或“从某偏移开始的切片”。这时别硬改底层，用 list(buffer) 转换虽简单，但每次转都 O(n)，高频访问就成瓶颈。
更优解是封装一层，利用 deque 的 rotate() 和只读切片能力：
立即学习“Python免费学习笔记（深入）”；
class RingBuffer:
def __init__(self, size):
self._data = deque(maxlen=size)
<pre class="brush:php;toolbar:false;">def append(self, item):
self._data.append(item)
def get_last(self, n):
# 返回最近 n 个元素（按时间顺序，最老在前，最新在后）
if n <= 0:
return []
k = min(n, len(self._data))
# 临时旋转使最老元素在左端，转成 list 后切片
temp = deque(self._data)
temp.rotate(-len(self._data) + k) # 关键：把倒数 k 个移到左端
return list(temp)[:k]
注意：rotate() 是就地操作且耗时 O(k)，所以这个 get_last() 是 O(n)；若需频繁随机索引，建议改用数组+模运算的手写实现，而非强依赖 deque。
deque 环形缓冲在多线程下的安全边界
deque.append() 和 deque.popleft() 是 CPython 中原子操作，但“检查长度 + 再 append”这种两步逻辑不是原子的——这就是典型竞态点。
- 只要只用
append()/appendleft()写，maxlen自动管理，就是线程安全的 - 但若混用
pop()、remove()或手动len()判断再操作，就必须加threading.Lock - 避免在信号处理函数（如
signal.signal）中操作deque，因 CPython 的 GIL 在信号中断时可能未完全覆盖
什么场景下不该用 deque 做环形缓冲
当你要做以下事情时，deque 反而添乱：
- 需要低延迟访问中间位置（比如音频处理中每毫秒查 buffer[1024]）→ 用
array.array或numpy.ndarray配合模索引 - 缓冲区大小在运行时动态变化 →
deque的maxlen创建后不可改，只能重建新实例 - 需序列化（如存到文件或网络传输）→
deque本身不可 pickle（虽实际可，但含maxlen时行为易被误读），不如转list再存 - 内存极度受限（嵌入式）→
deque每个节点有指针开销，纯数组更紧凑
环形缓冲真正的复杂点不在“怎么装满再覆盖”，而在于“谁在什么时候读、谁在什么时候写、是否允许读写并发、是否要阻塞等待”。deque 只解决最表层的容器语义，上层协议和同步逻辑得自己兜住。
