Java中Stack类被弃用因其继承Vector导致LIFO语义破坏、同步开销大、命名不统一；官方推荐用Deque接口+ArrayDeque实现，坚持push/pop/peek以保障栈语义和可维护性。
Java里Stack类为什么被官方弃用
因为 Stack 是个设计有硬伤的“历史包袱”：它继承自 Vector，而 Vector 本身是线程安全但低效的数组实现。这种继承让 Stack 暴露了本不该有的随机访问能力，也拖累了单线程性能。
- 它能调用
add(int index, E element)、remove(int index)等非栈操作，直接破坏 LIFO 语义 - 所有方法都带
synchronized，哪怕你只在单线程里用，也要为锁付出开销 - 命名不统一：
push/pop和集合框架主流的add/remove风格冲突
用Deque替代Stack的正确写法
Java 官方明确推荐用 Deque 接口 + ArrayDeque 实现来模拟栈，这才是现代写法。
-
ArrayDeque是非线程安全、无同步开销、内存紧凑的双端队列，压栈/出栈都是 O(1) 均摊时间 - 必须用
push()和pop()（不是add()/remove()），才能保持栈语义 - 错误示范：
new LinkedList()虽然也能用，但比ArrayDeque多指针开销、缓存局部性差，不推荐
正确示例：
Deque<Integer> stack = new ArrayDeque<>();<br>stack.push(1);<br>stack.push(2);<br>System.out.println(stack.pop()); // 输出 2
Stack和Deque在LIFO行为上的关键差异
Stack 的 pop() 返回值类型是 E，而 Deque.pop() 抛出 NoSuchElementException；更关键的是，Deque 的 API 设计强制你关注空栈边界——这反而是好事。
-
Stack.peek()在空时返回null（对基本类型会 NPE），Deque.peek()同样返回null，但语义更清晰 -
Deque支持offerFirst()/pollFirst()等底层操作，但日常栈场景只需坚持用push/pop/peek - 如果把
Deque当栈用，千万别混用addLast()或removeFirst()—— 这会让逻辑变模糊，也失去可读性
什么时候真该用Stack（几乎不存在）
除非你在维护 JDK 1.0–6 的遗留系统，或者必须和某个强依赖 Stack 类签名的老接口对接，否则没有理由选它。
- 哪怕需要线程安全，也不该用
Stack，而应选Collections.synchronizedDeque(new ArrayDeque())或ConcurrentLinkedDeque - 单元测试中若看到
Stack，大概率是作者没更新知识库，建议直接重构
真正容易被忽略的点是：很多人以为“只要行为像栈就行”，但 API 的约束力才是保障长期可维护性的关键——Deque 不让你乱插中间元素，Stack 却放任你破坏契约。
