为何优先使用Deque替代Stack、LinkedList替代Queue？为何概念用ArrayList实战用前者？

Great questions—these are exactly the kind of practical vs. conceptual gaps that trip up a lot of new Java developers! Let’s break this down step by step.

Deque vs. Stack: Fixing Legacy Flaws #

• The Stack class is a leftover from Java 1.0, inheriting directly from Vector. While Vector is thread-safe, this adds unnecessary synchronized overhead for most single-threaded scenarios—you’re paying a performance cost you don’t need.
• Worse, Stack inherits all of Vector’s list-specific methods (like add(int index, E element)), which break the pure LIFO stack contract. It’s easy to accidentally write code that violates stack behavior, leading to hard-to-track bugs.
• The Deque interface was built to solve these problems. It provides a clean, consistent API for LIFO stack operations (push(), pop(), peek()) and also supports FIFO queue operations if needed. Implementations like ArrayDeque are optimized for speed (no synchronization overhead) and avoid the bloated, inconsistent methods of Stack. The recommended pattern:

  Deque<Integer> stack = new ArrayDeque<>();
  

LinkedList vs. Queue: Interface + Flexibility #

• First, remember: Queue is just an interface—you can’t instantiate it directly. You need a concrete implementation, and LinkedList is a top choice for good reason:
  • It implements both Queue and Deque, so it’s flexible enough to handle standard queue operations (offer(), poll(), peek()) and can even act as a stack if needed.
  • For core queue actions (adding to the tail, removing from the head), LinkedList offers O(1) time complexity, which is optimal.
  • Unlike specialized Queue implementations (like PriorityQueue for ordered queues), LinkedList fits the "plain FIFO queue" use case perfectly, with an API that aligns cleanly with the Queue interface.

• Tutorials prioritize learning simplicity over real-world performance:

  • ArrayList is the first collection most Java learners encounter, so using it to simulate stacks/queues lets instructors focus on core logic (LIFO/FIFO) without introducing new interfaces or classes. For example:
    • A stack can be simulated with add() (append to end) and remove(size()-1) (remove last element)
    • A queue can be simulated with add() (append to end) and remove(0) (remove first element)
  • This approach keeps the focus on what a stack/queue does, not how to use the "proper" Java API.

• Real-world code prioritizes performance and correctness:

  • Simulating a queue with ArrayList is terrible for performance: remove(0) requires shifting every element forward, which is O(n) time complexity. For large datasets, this creates a massive bottleneck.
  • Even simulating a stack with ArrayList has downsides: while add() and remove(size()-1) are O(1), ArrayList has overhead from resizing its underlying array, and there are no guardrails to prevent accidental non-stack operations (like inserting elements in the middle).
  • ArrayDeque and LinkedList are purpose-built for these operations: they have optimized implementations, clean APIs that enforce stack/queue behavior, and follow Java’s best practices for interface-based programming (using Deque/Queue interfaces instead of concrete classes makes code more flexible to future changes).

内容的提问来源于stack exchange，提问作者Mj choi