java中stack类不推荐使用，因其继承vector导致接口污染、同步开销大且违背栈的lifo本质；arraydeque是官方推荐替代，语义清晰、性能更优、api干净。
Java 中的 Stack 类不推荐使用，根本原因在于它直接继承 Vector——这不是权宜之计，而是设计层面的结构性缺陷。它既没带来真正需要的能力，又强加了大量冗余负担。现代开发中，ArrayDeque 是官方明确推荐、语义清晰、性能更优的替代选择。
违背“栈”本质的继承关系
Stack 并不是一种特殊的 Vector，它只是需要后进先出（LIFO）行为。但继承让 Stack 被迫公开所有 Vector 的方法：
-
insertElementAt(0, x)可把元素插到栈底，破坏 LIFO -
removeElementAt(2)能删掉中间任意位置，栈结构瞬间失效 -
get(0)返回栈底而非栈顶，与peek()含义冲突 -
search(Object)这类线性查找操作，根本不属于栈语义
这些方法的存在，不是功能增强，而是接口污染，让使用者容易误用，也模糊了抽象边界。
同步开销拖累单线程性能
Vector 的每个 public 方法都带 synchronized，而 Stack 全盘继承。这意味着：
- 哪怕你在单线程里高频调用
push()和pop()，每次都要进锁、检查 monitor、释放锁 - 实测显示：万级元素压栈场景下，
ArrayDeque吞吐量通常是Stack的 3–5 倍 - 线程安全不该由数据结构默认承担；真需要时，应显式包装（如
Collections.synchronizedDeque()）或选用ConcurrentLinkedDeque
ArrayDeque 作为栈使用的实际优势
ArrayDeque 不是“勉强能用”，而是专为高效双端操作设计的现代实现：
- 底层是容量为 2 的幂次方的循环数组，索引计算用位运算（如
(head - 1) & (elements.length - 1)），比取模更快 -
push()等价于addFirst()，pop()等价于removeFirst()，所有操作均摊时间复杂度为 O(1) - 不允许存
null，消除了pop()返回null时“栈空”还是“存了 null”的歧义 - API 干净：只暴露栈所需方法，无冗余操作，语义一目了然
写法也简洁自然：Deque<string> stack = new ArrayDeque(); stack.push("hello");</string>
迁移时需注意的细节
从 Stack 切换到 ArrayDeque 大多平滑，但有几点要留意：
- 旧代码若用了
Stack.search()，需改用遍历或重构逻辑（ArrayDeque不提供内置查找） -
ArrayDeque.iterator()从栈底开始遍历（插入顺序），而Stack.toString()显示的是“栈顶在右”，日志依赖该格式时需调整 - 若原先靠
Stack的同步“凑合”处理并发，迁移到ArrayDeque后必须显式加锁或换用线程安全实现
它不掩盖问题，只暴露问题——比如本该用状态机的地方硬套栈，换过去后反而更容易发现设计偏差。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
