如何在 Java 中使用 Stack 类实现后进先出的栈结构

如何在 Ja va 中使用 Stack 类实现后进先出的栈结构

开门见山，先说一个核心结论：在 Ja va 中，Stack 类已经是一个“历史遗留”组件，不推荐在新代码中使用。 它的问题根源在于其设计——继承自早已过时的 Vector 类。这不仅带来了不必要的同步性能开销，更关键的是，它破坏了栈应有的封装性。想想看，一个栈对象居然能用 get(i) 方法随意访问中间任意位置的元素，这还叫栈吗？

正确的做法是使用 Deque 接口及其实现类（如 ArrayDeque）来模拟栈操作。后者性能更优，API 设计也更纯粹、更符合栈的抽象。

为什么不该用 Stack 类

深入一层看，Stack 本质上就是一个“披着栈外衣”的 Vector。它所有的方法都加上了 synchronized 关键字，这意味着即使在单线程环境下，也会产生额外的同步开销，纯属浪费。它的 push() 和 pop() 方法，底层调用的其实是 Vector 的 addElement() 和 removeElementAt(size()-1)，语义上存在冗余。

最要命的是，它从 Vector 那里继承了一整套与栈概念格格不入的方法，比如 elementAt()、setSize() 等。这些方法的存在，等于公开邀请开发者去破坏栈的后进先出（LIFO）原则。因此，JDK 官方文档早已明确建议：应该使用 Deque 接口及其实现来替代 Stack。 其中，ArrayDeque 因其基于数组、无容量限制（动态扩容）且非线程安全的特性，成为大多数场景下的首选。

用 ArrayDeque 替代 Stack 的正确写法

替换起来非常简单。原来声明栈的代码：

Stack stack = new Stack<>();

现在可以无缝换成：

Deque stack = 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 DequeStack extends 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() 却抛出异常，那时就不得不去翻阅令人头疼的源码了。防患于未然，总是更明智的选择。