ArrayDeque与Stack性能对比分析

ArrayDeque 是 Java 中 Stack 的现代、高效且语义严谨的替代方案，自 JDK 1.6 起官方已明确弃用 Stack，因其继承 Vector 导致 LIFO 语义失效、全方法同步严重拖累单线程性能、低效数组扩容等根本性设计缺陷；相比之下，ArrayDeque 基于优化的循环数组实现，吞吐量可达 Stack 的 4 倍，无锁、无冗余操作、扩容更轻量，但需注意其禁止 null 元素、非线程安全及不支持随机访问等关键差异——正确迁移不仅能大幅提升性能，更能推动代码回归数据结构本质，避免隐性坑在高并发或边界场景下突然爆发。

ArrayDeque 就是 Stack 的现代替代品，别再用 Stack 了

Java 官方从 JDK 1.6 起就明确不推荐 Stack，JDK 9+ 的文档里直接写“A more complete and consistent set of LIFO stack operations is provided by the Deque interface”——意思是：要栈操作，就用 Deque，别碰 Stack。这不是建议，是淘汰声明。

为什么 ArrayDeque 压倒性胜出：三个硬伤 Stack 根本改不了

Stack 的问题不是“不够好”，而是设计上就卡死在 1995 年：

• Stack 继承自 Vector，所以它能调用 add(2, x)、remove(0)、set(3, y) —— 这些操作让栈不再是栈，LIFO 语义彻底失效
• 所有方法都带 synchronized，单线程下也强制锁，实测压入 10 万元素，ArrayDeque 吞吐量通常是 Stack 的 4 倍左右
• 底层用普通数组扩容（复制整个数组），初始容量 10，而 ArrayDeque 用循环数组 + 位运算索引（(i + 1) & (length - 1)），扩容翻倍且无取模开销

怎么把旧 Stack 代码安全换成 ArrayDeque？关键三步

替换不是简单改类型，要注意行为差异和空值处理：

• 把 Stack s = new Stack<>(); 换成 Deque s = new ArrayDeque<>(); —— 推荐用接口声明，保留灵活性
• s.push(x) 和 s.pop() 可直接保留；但 s.peek() 在空时抛 NoSuchElementException，若需 null 安全，改用 s.peekFirst()
• Stack 允许 null，ArrayDeque 明确禁止 null 元素，插入前必须判空，否则抛 NullPointerException

ArrayDeque 不是万能的：两个真实限制你得知道

它快、干净、灵活，但不是银弹：

• 它不是线程安全的 —— 这反而是优点：多数业务栈根本不需要同步，强行加锁反而掩盖并发意图；真需要线程安全，用 Collections.synchronizedDeque(new ArrayDeque<>())，比 Stack 更可控
• 它不支持随机访问 —— 没有 get(int index)，也没 search(Object) 这种遗留方法；如果你真需要查某个元素位置，说明你用错了数据结构，该换 ArrayList 或加索引缓存

真正容易被忽略的，是 null 禁止和线程安全责任上移——这两点不提前踩坑，上线后可能只在高并发或边界数据下才暴露。

到这里，我们也就讲完了《ArrayDeque与Stack性能对比分析》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！