Java集合框架中的LinkedList与栈操作

应使用Deque接口声明LinkedList栈，仅调用push/pop/peek等栈方法；混用List操作会破坏LIFO语义，且ArrayDeque在多数场景下性能更优、内存更高效。

LinkedList 实现栈时为什么不能直接用 push/pop

Java 的 LinkedList 实现了 Deque 接口，因此自带 push()、pop()、peek() 方法——但这些方法操作的是链表**头部**（即首节点），符合 LIFO 语义。问题在于：如果代码中混用了 add() / removeLast() 等列表式操作，会破坏栈结构的预期行为。

常见错误现象：

• 调用 list.add("a"); list.push("b") 后，pop() 返回 "b"，但 get(0) 是 "a"，索引和栈顶错位
• 用 forEach 遍历时顺序与出栈顺序相反，误以为“栈底在前”

正确创建栈语义的 LinkedList 实例

应当明确使用 Deque 类型声明，并只调用双端队列定义的栈方法，避免暴露 List 接口行为：

Deque stack = new LinkedList<>();
stack.push("first");
stack.push("second");
String top = stack.pop(); // "second"
boolean isEmpty = stack.isEmpty(); // true 当栈空

关键点：

• 永远用 Deque 接口类型引用，不写 LinkedList stack = new LinkedList();
• 禁止调用 add(int, E)、get(int)、remove(int) 等随机访问方法
• push(E) 等价于 addFirst(E)，pop() 等价于 removeFirst()，性能是 O(1)

与 ArrayDeque 比较：什么情况下不该选 LinkedList 做栈

虽然 LinkedList 支持栈操作，但绝大多数场景下 ArrayDeque 是更优选择：

• ArrayDeque 内存局部性好，扩容策略更可控；LinkedList 每个元素额外占用两个指针内存，GC 压力更大
• 当栈深度稳定或可预估（如解析嵌套 JSON、括号匹配），ArrayDeque 的数组结构比链表快 2–3 倍
• 只有在极端场景（如需频繁在栈中间插入/删除，且已确认是瓶颈）才考虑 LinkedList；但此时已不是纯栈语义

错误示范：

LinkedList stack = new LinkedList<>(); // 不推荐，即使语法合法

调试栈行为时最容易忽略的陷阱

栈空时调用

pop() 或 peek() 会抛 NoSuchElementException，但这个异常不带上下文信息，容易误判为数据源问题：

• 永远在 pop() 前检查 isEmpty()，不要依赖 try-catch 捕获来控制流程
• peek() 返回 null 当且仅当栈为空且元素类型为 nullable（如 String），对 int 等基本类型包装类要小心 NPE
• 日志中打印栈状态时，别用 toString()——它输出的是从头到尾的链表顺序，和栈顶到底的逻辑顺序相反

真正需要观察栈顶几个元素时，应手动遍历或转成数组：

Object[] snapshot = stack.toArray(); // 栈顶在 index 0