Deque接口通过支持两端O(1)增删解决Queue单向操作局限；推荐ArrayDeque而非LinkedList，因其循环数组结构更高效；操作应优先选用offer/poll系列以避免异常。
Deque 接口解决了单向队列无法高效两端操作的问题
Java 的 Queue 接口只支持在尾部入队、头部出队（FIFO），一旦需要在头部插入或尾部删除（比如实现栈、滑动窗口、撤销操作），用 LinkedList 做 Queue 就会退化成 O(n) 时间——因为 removeLast() 或 addFirst() 在纯 Queue 语义下不被允许。而 Deque（Double-ended Queue）明确把「两端都可增删」作为核心契约，让这些操作稳定在 O(1)。
add() / offer() / push() 这些方法到底该用哪个
它们都往队首（栈顶）加元素，但行为差异直接影响错误处理逻辑：
-
addFirst(e)和push(e)功能等价，但前者是Deque接口方法，后者是栈语义别名；失败时都抛IllegalStateException -
offerFirst(e)是更安全的选择：容量受限实现（如ArrayDeque满了）时返回false，不抛异常 - 别混用
push()和addLast()——语义错位会导致逻辑混乱，比如用push()入队、pollLast()出队，就不是标准栈行为了
ArrayDeque vs LinkedList：选错实现类会让性能掉一截
ArrayDeque 是大多数场景的默认选择，但它不是“数组+双向链表”的混合体，而是循环数组。这意味着：
- 内存局部性好，遍历和随机访问快；
LinkedList每次指针跳转都是缓存不友好操作 -
ArrayDeque不支持null元素（调用add(null)会抛NullPointerException），而LinkedList可以存null - 扩容代价隐含：
ArrayDeque扩容是复制整个数组，但触发频率低；LinkedList每次新增只分配一个节点，但总内存开销大、GC 压力高
Deque<String> deque = new ArrayDeque<>(); // 推荐 // 不要仅因“它叫 LinkedList”就选它来做双端队列 Deque<String> badChoice = new LinkedList<>();
poll() / remove() / pop() 的异常策略必须看清楚
这三个方法都从队首取并移除元素，但空容器时的行为完全不同：
立即学习“Java免费学习笔记（深入）”；
-
pollFirst()：空时返回null，最安全，适合不确定是否非空的场景 -
removeFirst()：空时抛NoSuchElementException，适合你「确定有值」且想用异常中断流程的情况 -
pop()：和removeFirst()完全等价，只是栈语义命名，别误以为它更轻量
用错会导致生产环境出现意料外的异常——比如把 removeFirst() 写在循环里，但没校验空状态，一空就崩。
ArrayDeque + offerFirst()/pollFirst() 组合，既避免异常干扰主逻辑，又守住性能底线。边界情况比想象中多，比如并发修改、null 元素、容量突增，这些在接口层面不体现，但具体实现类会立刻暴露。 
