应使用 deque 替代 stack 实现 lifo：stack 是遗留类，继承 vector 破坏封装、性能差且线程不友好；deque（如 arraydeque）语义清晰、o(1) 高效、编译期安全，符合现代 java 规范。

用 Deque 替代 Stack 实现后进先出（LIFO）逻辑，核心优势在于更规范、更高效、更安全——Stack 是遗留类，设计上违背了面向对象原则，而 Deque 是 Java 集合框架中专为双端队列设计的接口，其 push()/pop()/peek() 方法语义清晰、性能可控、线程更友好。

避免继承带来的设计缺陷

Stack 继承自 Vector，导致它“既是栈又是向量”，暴露了本不该用于栈操作的方法（如 get(int)、elementAt(int)、removeElementAt(int)）。这破坏了封装性，容易误用。例如，直接调用 stack.get(0) 会取到栈底元素，与 LIFO 意图完全相悖。

• 使用 Deque（如 ArrayDeque）可只暴露栈语义方法：仅允许 push()、pop()、peek()、isEmpty()
• 编译期即限制非法访问，提升代码可读性和可维护性

获得更好的时间复杂度保障

Stack 因继承 Vector，所有方法默认同步（synchronized），带来不必要的性能开销；且 Vector 的扩容机制在栈场景下不够高效（每次翻倍 + 同步锁）。

• ArrayDeque 是非同步实现，push()/pop() 均为 O(1) 均摊时间复杂度，无锁开销
• 底层基于循环数组，空间利用率高，比链表实现（如 LinkedList 作为 Deque）缓存局部性更好
• 若需线程安全，可显式包装为 Collections.synchronizedDeque()，职责更清晰

符合现代 Java 集合规范与演进方向

Stack 自 Java 1.0 存在，但官方文档早已明确标注为“legacy class”，不推荐新代码使用；而 Deque 自 Java 6 引入，是集合框架中正式支持栈语义的标准方式。

• Deque 接口定义了统一的栈操作命名（push/pop/peek），语义比 Stack 的 push/pop/peek 更一致（Stack 的 pop 会抛异常，peek 不抛，行为边界模糊）
• 主流 IDE 和静态分析工具（如 IntelliJ、SonarQube）会对 Stack 用法发出警告，提示迁移到 Deque
• Spring、Guava 等主流库内部栈逻辑均基于 Deque，保持技术栈一致性

迁移成本低，API 几乎无缝对接

将 Stack<e></e> 替换为 Deque<e></e> 只需少量改动，且行为完全兼容：

• 原 new Stack() → 改为 new ArrayDeque()
• stack.push(e)、stack.pop()、stack.peek() 可直接保留（Deque 接口已定义同名方法）
• stack.empty() → 改为 deque.isEmpty()（更符合集合命名习惯）
• 注意：Stack 的 search(Object) 是非标准栈操作，若业务强依赖，需自行实现或改用其他结构