如何在 Java 中使用 Stack 类实现后进先出的栈结构
开门见山，直接给出核心结论：在 Java 编程中，Stack 类已被视为“遗留类”，不推荐在新项目中使用。 其根本问题源于其设计——它直接继承了过时的 Vector 类。这不仅引入了不必要的同步性能损耗，更重要的是，它破坏了栈数据结构应有的封装性。试想，一个栈对象竟然可以通过 get(i) 方法随意访问中间任意位置的元素，这完全违背了栈（LIFO）的基本原则。
现代 Java 开发的最佳实践是使用 Deque 接口及其实现类（例如 ArrayDeque）来模拟栈操作。后者不仅性能更优越，其 API 设计也更加纯粹，更符合栈的抽象定义。
为什么不该用 Stack 类
深入剖析，Stack 本质上是一个“披着栈外衣”的 Vector。其所有公共方法都标记了 synchronized 关键字，这意味着即使在单线程环境下，也会产生额外的同步开销，造成性能浪费。它的 push() 和 pop() 方法，底层实际调用的是 Vector 的 addElement() 和 removeElementAt(size()-1)，存在语义上的冗余。
最关键的是，它从 Vector 父类继承了大量与栈概念相悖的方法，例如 elementAt()、setSize() 等。这些方法的存在，无异于允许开发者随意破坏栈的后进先出（LIFO）约束。因此，JDK 官方文档早已明确建议：应当使用 Deque 接口及其实现类来替代 Stack。 其中，ArrayDeque 因其基于数组、支持动态扩容且非线程安全的特性，成为绝大多数场景下的首选替代方案。
用 ArrayDeque 替代 Stack 的正确写法
替换操作非常简便。原先声明栈的代码：
Stackstack = new Stack<>();
现在可以无缝更改为：
Dequestack = new ArrayDeque<>();
核心栈操作方法几乎可以一一对应，迁移成本极低：
- 入栈：
stack.push("a")→ 保持不变（ArrayDeque同样实现了push方法）。 - 出栈：
stack.pop()→ 行为完全一致，返回并移除栈顶元素。 - 查看栈顶：
stack.peek()→ 查看但不移除，用法与Stack完全相同。 - 判断空栈：
stack.isEmpty()→ 直接使用，毫无差异。
这里有一个重要细节需要注意：ArrayDeque 不允许存储 null 元素，而旧的 Stack 类则允许。如果现有业务逻辑确实依赖在栈中存储 null，那么或许应该重新审视这个栈本身的设计是否合理。
遇到 EmptyStackException 怎么办
无论是使用旧的 Stack.pop() 还是新的 ArrayDeque.pop()，在空栈上执行出栈操作时，都会抛出 EmptyStackException。这并非程序错误，而是容器类定义的标准契约行为。
安全的做法始终是“先检查，后操作”：
if (!stack.isEmpty()) {
String top = stack.pop();
}
切忌依赖 try-catch 块来控制正常的业务逻辑流。这不仅可能掩盖程序其他部分抛出的真实异常，还会带来不必要的性能损耗。一些遗留代码可能使用 stack.size() > 0 进行判断，对于 ArrayDeque 这没有问题。但需要注意的是，对于某些特定的 Deque 实现（例如并发场景下的 ConcurrentLinkedDeque），size() 方法的计算开销可能较大或结果不精确。因此，最稳妥、最通用的做法就是坚持使用 isEmpty() 方法。
如果必须兼容老 Stack 接口怎么办
在实际开发中，难免会遇到需要对接遗留系统，或者某些第三方库的 API 强制要求传入 Stack 类型参数的情况。此时，我们的目标是以最小的侵入性来解决问题。
一个优雅的解决方案是采用适配器模式，而不是直接继承 Stack 或对其进行简单包装：
public class DequeStackextends Stack { private final Deque delegate = new ArrayDeque<>(); @Override public E push(E item) { delegate.push(item); return item; } @Override public synchronized E pop() { if (delegate.isEmpty()) throw new EmptyStackException(); return delegate.pop(); } // 其他方法同理，只转发到 delegate，屏蔽 Vector 特性 }
这个方案有几个关键优势：
- 彻底重写：重写所有
Stack的方法，确保内部逻辑全部委托给高效的ArrayDeque实例。 - 保留签名：方法上保留
synchronized关键字仅仅是为了满足Stack原有的方法签名约定，内部委托操作实际上已无需同步。 - 严格封装：绝不对外暴露内部的
delegate对象，也绝不调用父类（Vector）的任何方法，从而彻底屏蔽掉Vector带来的不良特性和性能问题。
归根结底，技术选型的难点往往不在于语法本身，而在于对设计原则的深刻理解。栈（Stack）不仅仅是一个“能后进先出”的容器，它更意味着接口清晰、行为可预测、未来扩展无隐患。如果选错了底层实现，等到调试时，发现 Stack.size() 明明返回 5，但调用 peek() 却抛出异常，那时就不得不去深入排查令人头疼的源码了。防患于未然，总是更明智的选择。
