ArrayDeque 做栈比 Stack 快，因 Stack 继承 Vector 有同步开销，而 ArrayDeque 是非线程安全、数组实现、无锁的；用 push/pop/peek，初始化容量建议设为2的幂。
ArrayDeque 当栈用，比 Stack 快在哪
直接结论：ArrayDeque 做栈比 Stack 类快得多，核心原因是 Stack 继承自 Vector，所有操作都带同步开销，而 ArrayDeque 是非线程安全、数组实现、无锁的。
实操建议：
- 用
push()/pop()/peek()模拟栈行为，语义清晰，和Stack一致 - 避免调用
addFirst()或removeFirst()——虽然等价，但可读性差，也容易和队列逻辑混淆 - 初始化容量建议设为 2 的幂（如
new ArrayDeque(16)），减少扩容时的数组复制次数 - 别在多线程环境下裸用
ArrayDeque当栈——它不保证线程安全，真要并发请外包Collections.synchronizedDeque()或换ConcurrentLinkedDeque
ArrayDeque 当队列用，为什么比 LinkedList 更稳
ArrayDeque 作为队列（FIFO）时，性能通常优于 LinkedList，尤其在中等规模数据下：数组局部性好、内存占用低、GC 压力小；LinkedList 每个元素都是独立对象，指针跳转多，缓存不友好。
实操建议：
- 统一用
offer()入队、poll()出队、peek()查首——这是标准队列接口，也兼容Queue上游逻辑 - 别混用
addLast()和offer()：前者可能抛IllegalStateException（满时），后者返回false，更可控 - 注意
ArrayDeque没有容量限制（动态扩容），但扩容是 O(n) 操作；如果已知最大长度，初始化时指定容量能避免运行时抖动 -
LinkedList在频繁插入/删除中间节点时有优势，但纯队列场景几乎没胜算
ArrayDeque 的扩容机制怎么影响性能
ArrayDeque 底层是循环数组，扩容不是“加一格”，而是翻倍（从 16 → 32 → 64…），每次扩容都要拷贝整个有效段。所以高频小量扩容比低频大量扩容更伤性能。
常见错误现象：
- 反复
push()100 次后又clear()，再 push —— 数组不会缩容，内存占着不放，且下次扩容仍按当前容量翻倍 - 构造时传
0或负数，实际初始容量变成 1，很快触发第一次扩容，白白多一次复制
实操建议：
- 初始化容量宁稍大勿过小，比如预估最多 500 元素，直接
new ArrayDeque(512) - 不用
clear()来“重用”实例——它只清空引用，不缩容；真要复用，建议新建 - 监控堆内
Object[]实例数量（如用 JFR 或 VisualVM），异常增长可能就是ArrayDeque被反复创建又丢弃
哪些场景千万别用 ArrayDeque
它不是万能双端容器。有些需求看着像双端，但用 ArrayDeque 反而掉坑里。
使用场景与限制：
- 需要随机访问第 n 个元素？
ArrayDeque.get(n)是 O(n) —— 它没实现List，底层循环数组索引要模运算+偏移，别当ArrayList用 - 要迭代中删除当前元素？
Iterator.remove()支持，但效率不如ArrayList的removeIf()；若删除频繁，考虑先收集索引再批量删 - 元素类型是基本类型？
ArrayDeque只支持引用类型，装箱开销逃不掉；高频数值操作请用IntDeque等第三方库（如 Eclipse Collections） - 需要阻塞操作（如
take()阻塞直到有元素）？它完全不提供——得换LinkedBlockingDeque
最常被忽略的一点：ArrayDeque 不允许存 null，任何 offer(null) 或 push(null) 都会立即抛 NullPointerException，这个检查发生在入口，没法绕过。
