为何优先使用Deque而非Java内置Stack<>类？

作为从C++转Java的开发者，你关注到这个细节真的很关键——Java集合框架里有不少早期设计的遗留类，虽然还能用，但在性能、封装性和设计合理性上都有明显缺陷，咱们逐一拆解你的问题：

一、优先选择Deque实现栈的原因 #

Java官方文档推荐用Deque作为栈的实现，核心原因在于Stack类是设计上的遗留产物，存在诸多弊端，具体如下：

1. 不合理的继承关系
   Stack继承自Vector，这意味着它继承了Vector的所有公共方法（比如add(int index, E element)），直接破坏了栈的LIFO（后进先出）语义——你可以在栈的任意位置插入元素，完全违背了栈的封装性。而Deque作为接口，仅暴露符合栈操作的方法（push()、pop()、peek()），或者使用Deque标准的offerFirst()、pollFirst()、peekFirst()，严格保证栈的行为。
2. 不必要的线程安全开销
   Vector（以及Stack）的所有方法都加了synchronized关键字，强制实现线程安全，但这会带来额外的性能损耗。大多数场景下，我们不需要全局的线程安全，要么自己控制同步逻辑，要么使用Java并发包（java.util.concurrent）中更高效的线程安全集合（比如ConcurrentLinkedDeque），而非依赖遗留类的低效同步。
3. 灵活性与性能优势
   Deque有多种高效实现类可选：
   • ArrayDeque：基于动态数组实现，栈操作（push/pop）的时间复杂度是O(1)，比Stack性能更高；
   • LinkedList：基于链表实现，适合频繁插入删除的场景。
     而Stack只有一种基于Vector的实现，完全没有选择空间。
4. 符合现代集合框架设计
   Deque是Java集合框架的标准接口，完美融入了集合体系（支持Iterator、forEach等现代遍历方式），而Stack是早期Java的产物，没有实现Deque或Queue接口，在集合框架中显得格格不入，使用它会增加代码的不一致性。

二、应避免使用的其他Java内置集合类 #

除了Stack，这些遗留类也建议尽量避开：

• Vector：和Stack一样，方法全同步导致性能差，替代方案是ArrayList（非线程安全场景）或CopyOnWriteArrayList（线程安全场景）。
• Hashtable：遗留的哈希表实现，同样全方法同步，性能远不如HashMap；而且Hashtable不允许null键/值，HashMap则支持一个null键和多个null值。线程安全场景下推荐用ConcurrentHashMap，性能和扩展性都更好。
• Enumeration：迭代器的遗留版本，功能远不如Iterator或ListIterator——Enumeration只能遍历元素，没有remove()方法，也不支持fail-fast机制（并发修改时会抛出异常，避免脏读），完全被现代迭代器取代。
• Dictionary：抽象的键值对集合类，已经被Map接口完全取代，现在几乎没人使用，直接用HashMap、TreeMap等实现类即可。

内容的提问来源于stack exchange，提问作者P.K.