作为后端开发者，我们在日常的业务开发和算法实现中，经常会遇到需要使用栈（Stack）或队列（Queue）的场景。
然而，许多开发者在使用 Deque 时，往往只是机械地使用其中的某几个方法，却未曾深究过 Deque 庞大 API 矩阵背后的设计，更少有人注意到在将 Deque 当作 Stack 使用时，其 push/pop 与 peek 方法在异常处理机制上存在着一个微妙的"不统一"。
今天，我们就以 JDK 8 为例，结合 Deque 接口的两位核心设计者 Doug Lea 与 Joshua Bloch 的设计思路，深度解剖 Deque 接口的底层逻辑。
1. 为什么抛弃 Stack？
在讨论 Deque 之前，我们必须先明确旧的 java.util.Stack 到底有什么问题。
Java 集合框架的核心开发者 Joshua Bloch 在其名作 《Effective Java》 中，将 Stack 作为一个经典的反面教材进行了严厉批判：
"If you attempt to build a stack by extending a vector, you expose all of the vector's methods... A client could corrupt the stack by directly modifying the underlying vector." （如果你试图通过继承
Vector来构建栈，你暴露了Vector的所有方法...... 客户端可以直接修改底层向量从而破坏栈的约束。）
Stack 继承自 Vector，这意味着它不仅继承了极其低效的重量级 synchronized 锁，更致命的是，它打破了栈"后进先出（LIFO）"的封装语义。开发者竟然可以通过 stack.add(1, element) 或 stack.elementAt(2) 直接操作栈底的元素，这在数据结构的设计上是极其荒谬的。
正是基于填补这个历史设计缺陷的目的，在 JDK 1.6（JSR-166）中，并发大师 Doug Lea 与 Joshua Bloch 联手设计了全新的 java.util.Deque 接口。在 Deque 的官方 JavaDoc 中，两位作者明确写下：
"Deques can also be used as LIFO (Last-In-First-Out) stacks. This interface should be used in preference to the legacy Stack class."
（Deque 也可作为 LIFO 栈使用。应该优先使用此接口，而非遗留的 Stack 类。）
2. Deque 接口的核心设计矩阵
Deque 全称是 Double Ended Queue（双端队列）。它的核心特性是允许在队列的两端（头部和尾部）进行插入和删除操作。
为了满足不同场景下的需求，Doug Lea 与 Joshua Bloch 为 Deque 设计了一套高度对称的 API。这套 API 的设计维度有两个：
- 操作位置：头部（First） vs 尾部（Last）
- 失败处理机制 ：抛出异常（Throws exception） vs 返回特殊值（Returns special value，通常是
null或false）
这两个维度交叉组合，构成了 Deque 的 12 个基础操作 API：
| 操作类型 | 抛出异常 | 返回特殊值 |
|---|---|---|
| 头部插入 | addFirst(e) |
offerFirst(e) |
| 尾部插入 | addLast(e) |
offerLast(e) |
| 头部删除 | removeFirst() |
pollFirst() |
| 尾部删除 | removeLast() |
pollLast() |
| 头部查看 | getFirst() |
peekFirst() |
| 尾部查看 | getLast() |
peekLast() |
一些说明：
- 插入操作 ：在容量受限的 Deque（如
LinkedBlockingDeque）中，当容量已满时，抛出异常系列会抛出IllegalStateException，而返回特殊值系列会返回false。- 删除/查看操作 ：当 Deque 为空时，抛出异常系列会抛出
NoSuchElementException，而返回特殊值系列会返回null。- 无论是基于数组实现的
ArrayDeque还是基于链表实现的LinkedList，这 12 个基础操作的时间复杂度均被严格保证为 O(1) 或均摊 O(1)。
3. Deque 与 Queue、Stack 的角色切换
Deque 的强大之处在于它能力全面：它直接继承自 java.util.Queue 接口，并且在语义上完全覆盖了 java.util.Stack。
3.1 扮演 Queue (FIFO)
当把 Deque 当作普通队列使用时，通常遵循 FIFO（先进先出）原则。元素从尾部进入，从头部移出。Deque 直接继承了 Queue 的 API，并在内部将其路由到双端队列的具体方法：
| Queue 方法 | 等价的 Deque 方法 | 行为描述 |
|---|---|---|
add(e) |
addLast(e) |
尾部插入（满则抛异常） |
offer(e) |
offerLast(e) |
尾部插入（满则返回 false） |
remove() |
removeFirst() |
头部删除（空则抛异常） |
poll() |
pollFirst() |
头部删除（空则返回 null） |
element() |
getFirst() |
头部查看（空则抛异常） |
peek() |
peekFirst() |
头部查看（空则返回 null） |
3.2 扮演 Stack (LIFO)
JDK 早期提供的 java.util.Stack 存在严重的设计缺陷：它继承自 Vector，这意味着它的所有方法都自带了 synchronized 重量级锁，导致并发性能极差；此外，继承结构破坏了封装性，暴露了按索引操作元素的方法，这在栈的数据结构语义中是不合法的。
因此，Deque 被官方指定为栈的替代品，并专门为此提供了栈的经典 API：push、pop 和 peek。
在 LIFO（后进先出）模式下，所有的入栈和出栈操作都在同一端（通常约定为头部 First）进行：
| Stack 操作语义 | Deque 中的对应方法 | 等价的基础双端方法 |
|---|---|---|
| 入栈 | push(e) |
addFirst(e) |
| 出栈 | pop() |
removeFirst() |
| 查看栈顶 | peek() |
peekFirst() |
4. Stack 模式下异常处理的"妥协"
如果你仔细观察上面的 API 映射，并结合我们在第2节总结的"异常 vs 特殊值"矩阵，你会发现一个极其反直觉的现象。
当我们把 Deque 当作栈使用时，面临空栈（或满栈）的情况：
push(e)等价于addFirst(e)-> 抛出异常 (IllegalStateException)pop()等价于removeFirst()-> 抛出异常 (NoSuchElementException)peek()等价于peekFirst()-> 返回 null (不抛出异常)
为什么 push 和 pop 走的是"抛出异常"流派，而同为栈操作的 peek 却悄悄走入了"返回特殊值"流派？ 为什么这里的设计不是统一的（比如 peek 应该映射到 getFirst() 从而抛出 NoSuchElementException）？
要理解这个 API 设计的异常割裂，我们需要跳出单点思维，站在接口继承体系设计 和历史兼容性的角度去剖析。
4.1 模拟老旧的 Stack
Doug Lea 在设计 Deque 的 Stack 模式 API 时，首要目标是降低开发者的迁移成本。老旧的 java.util.Stack 的行为是怎样的？
Stack.push(e)：容量不足时自动扩容（Vector 机制），但在某些极端底层受限情况下会抛出异常。Stack.pop()：当栈为空时，抛出EmptyStackException。
为了与老用户的习惯保持一致，Deque.pop() 必须在空栈时抛出异常（NoSuchElementException 充当了替代品）。因此，pop() 被映射到了 removeFirst()，同理 push() 映射到了 addFirst()。
4.2 接口的里氏替换原则
既然老旧的 Stack.peek() 在空栈时也会抛出 EmptyStackException，那为什么 Deque.peek() 不抛出异常呢？
根本原因在于方法名冲突与接口继承的契约限制。
看一眼 JDK 源码的类继承图：
java
public interface Deque<E> extends Queue<E> {
// ...
}Deque 继承自 Queue。而在 Queue 接口中，早就已经定义了 peek() 方法：
java
public interface Queue<E> extends Collection<E> {
/**
* Retrieves, but does not remove, the head of this queue,
* or returns null if this queue is empty.
*/
E peek();
}Queue 接口的契约清楚地写着：peek() 方法在队列为空时必须返回 null，绝不能抛出异常。
根据面向对象设计的里氏替换原则（Liskov Substitution Principle） ，子接口（Deque）不能改变父接口（Queue）已声明的方法的语义契约。如果 Deque 强行覆盖 peek() 让其在为空时抛出异常，那么所有将 Deque 向上转型为 Queue 进行操作的多态代码将会面临不可预期的行为。
4.3 设计权衡
留给 JDK 设计者的路只有两条：
- 换个名字 ：为栈操作专门发明一个新的查看栈顶的方法，比如叫
peekStack()或top()，并让它映射到getFirst()（抛异常）。 - 妥协复用 ：直接复用继承自
Queue的peek()方法名，忍受它"返回 null"的语义，从而破坏栈操作 API（push/pop/peek）在异常处理上的一致性。
最终，为了保持核心 API 方法名的高度认知一致性（开发者对 push、pop、peek 已经有了多年的肌肉记忆），设计者选择了妥协复用。
这就是为什么在 Deque 中，push 和 pop 会抛出异常，而 peek 却返回 null 的原因。这也是 Java API 演进过程中，为了平衡"向下兼容"、"接口多继承隔离"和"开发者习惯"而留下的一个经典的微小设计瑕疵。
5. 总结与建议
通过追踪 Doug Lea 与 Joshua Bloch 的设计轨迹，我们不难发现，即便是 JDK 核心 API 的设计，也是在"向下兼容"、"接口隔离"和"开发者习惯"之间不断博弈与取舍的过程。
基于以上的分析，在日常开发工作中，我有以下两条建议供参考：
-
如果追求极致的语义一致性，请放弃 push/pop/peek：
与其记住
peek和pop异常处理的不同，不如彻底抛弃这种"模拟语义"，直接使用带有明确方向标识的First/Last组 API。这样可以在 Code Review 阶段消除由于null返回值或NoSuchElementException带来的隐患。- 需要抛异常的栈 ：统一使用
addFirst/removeFirst/getFirst。 - 不抛异常的栈 ：统一使用
offerFirst/pollFirst/peekFirst。
- 需要抛异常的栈 ：统一使用
-
不要插入 null 值：
正如 JDK 官方文档所警告的，强烈建议不要向
Deque中插入null元素（尽管LinkedList允许）。因为peek()和poll()使用返回null来表示集合为空，如果插入了真实的null元素就会导致混乱。
源码之下无秘密。探究 API 的设计不仅能帮我们避开使用上的暗坑，更能让我们学习到顶级工程师在面对历史包袱与规范约束时，是如何做架构取舍的。
这种在"理想的面向对象契约"与"现实的历史兼容性"之间寻找平衡的艺术，其实正是我们日常进行系统重构和复杂业务迭代时最真实的写照。希望这次分析，能让你在下次敲下这些基础 API 时，多一份知其所以然的笃定与从容。