官方推荐用 ArrayDeque 替代 Stack，核心原因是 Stack 冗余同步、接口污染、性能差、语义模糊；ArrayDeque 基于循环数组高效实现栈操作，无同步开销，接口纯净且符合 LIFO 契约。
官方推荐用 ArrayDeque 替代 Stack，核心原因不是“功能不够”，而是 Stack 的设计已严重偏离现代 Java 的工程实践：它冗余同步、接口污染、性能拖累、语义模糊。真正该用的不是“Stack 的升级版”，而是用符合 LIFO 契约的 Deque 接口 + 高效实现类 ArrayDeque。
同步开销真实存在，单线程也慢
Stack 继承自 Vector，所有 public 方法（push()、pop()、peek()、size()）都带 synchronized。这意味着哪怕你在单线程里连续压入 10 万个整数，每次调用都要走完整的锁进入/monitor 检查/锁释放流程——纯属无意义开销。
- 实测显示：万级元素栈操作中，
ArrayDeque吞吐量通常是Stack的 3–5 倍 - 锁不该由容器默认承担；需要线程安全时，应显式包装：
Collections.synchronizedDeque(new ArrayDeque()) - 强制同步掩盖了并发意图，反而让代码更难推理和调试
ArrayDeque 底层高效且专为栈优化
ArrayDeque 是循环数组实现，所有栈操作（push()/pop()）都在头部（head 端）完成，全程无扩容干扰、无索引越界检查、无对象头锁竞争。
- 容量始终是 2 的幂次方，索引用位运算计算：
(head - 1) & (elements.length - 1)，比取模快得多 - 扩容按 2 倍增长，复制时分两段搬移，保持逻辑顺序；初始容量仅 8，比
Stack的 10 更轻量 - 不允许存
null：消除了pop()返回null是“空栈”还是“存了 null”的歧义
接口干净，杜绝误用
Stack 因继承 Vector，暴露了完全违背 LIFO 语义的方法：add(int, E)、remove(int)、set(int, E) 等。这些方法让一个“栈”可以被随意插删中间元素，彻底破坏栈结构。
- 下面这段代码能编译通过，但已不是栈：
Stack<integer> s = new Stack();<br>s.push(1); s.push(2);<br>s.add(0, 999); // 插到最底下<br>s.remove(1); // 删中间一个<br>// 结果：[999, 2] —— LIFO 被破坏</integer>
-
ArrayDeque实现的是Deque接口，只提供push()/pop()、offerFirst()/pollFirst()等契约明确的操作 - 声明类型应写成
Deque，IDE 不会提示危险方法，从 API 层就防住误用stack = new ArrayDeque();
Stack 是历史遗留，非设计演进
Stack 是 JDK 1.0 的产物，和 Vector、Hashtable 一样，属于早期为快速交付而妥协的设计。它没实现 Deque 接口，不支持现代集合的统一遍历、流式操作、函数式编程等能力。
- JavaDoc 明确写道：“A more complete and consistent set of LIFO stack operations is provided by the
Dequeinterface” - Oracle 官方早已将其标记为 legacy（遗留类），不建议在新项目中使用
- 替代方案不是“换个类似类”，而是拥抱接口抽象：
Deque既能当栈（LIFO），也能当队列（FIFO），复用性更高
