Java栈结构实现指南使用Stack类完成LIFO操作

如何在 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 的正确写法

替换操作非常简便。原先声明栈的代码：

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() 却抛出异常，那时就不得不去深入排查令人头疼的源码了。防患于未然，总是更明智的选择。