ArrayDeque缓存局部性更好因其循环数组使元素物理连续存储，CPU可高效预取相邻内存；而Stack基于Vector扩容开销大，LinkedList节点随机分布导致缓存命中率低。
为什么 ArrayDeque 的缓存局部性比 Stack 和 LinkedList 更好
Stack 是基于 Vector 实现的，内部数组虽连续，但只允许后端操作，且每次扩容复制开销大；LinkedList 是链表结构，节点在堆中随机分布，CPU 缓存行（cache line）利用率极低。ArrayDeque 则用循环数组实现，元素物理连续存储，遍历、头尾增删时 CPU 能高效预取相邻内存，缓存命中率显著提升。
-
ArrayDeque底层是Object[]数组，所有元素紧挨着存放 - 头尾操作通过两个索引
head和tail维护，不移动元素，仅更新指针 - 扩容时才触发数组复制，且采用 1.5 倍增长策略（
newCapacity = oldCapacity + (oldCapacity >> 1)），比Vector的 2 倍更节省空间和复制时间
如何正确初始化 ArrayDeque 避免频繁扩容
默认构造函数创建容量为 16 的数组，但若你明确知道队列峰值大小（比如处理固定批次的 1000 个任务），直接指定初始容量能彻底避免运行时扩容带来的数组复制与 GC 压力。
- 使用
new ArrayDeque(initialCapacity)，传入略大于预期最大尺寸的值（如预期最多 800 元素，设1024） - 不要传 0 或负数：会触发
initialCapacity == 0 ? 1 : initialCapacity的兜底逻辑，反而导致后续立即扩容 - 避免用
new ArrayDeque(collection)初始化大量数据：它会先调用collection.size()估算容量，再逐个addLast()，中间可能因扩容打断缓存连续性
头尾操作选对方法，别掉进“语义陷阱”
ArrayDeque 提供两套 API：带 First/Last 后缀的双端操作（推荐），和继承自 Deque 的 push/pop/peek（仅模拟栈语义）。混用易出错，且影响可读性与性能预期。
- ✅ 优先使用
addFirst()/addLast()、removeFirst()/removeLast()、peekFirst()/peekLast() - ❌ 少用
push()（等价于addFirst()）和pop()（等价于removeFirst()），除非你真在写栈逻辑 - ⚠️
element()和remove()是继承自Queue，实际调用peekFirst()/removeFirst()，但语义模糊，容易让人误以为是“队列前端”，建议显式写清意图
注意 null 元素限制与 fail-fast 行为
ArrayDeque 明确禁止 null 元素，插入时直接抛 NullPointerException。这不是 bug，而是设计取舍：省去对 null 的边界检查，简化内部逻辑，也避免用 null 作哨兵值干扰循环数组的空/满判断。
- 插入前务必确保对象非
null，尤其从外部集合或网络解析结果中取值时 - 迭代器是 fail-fast 的：若在迭代过程中被其他线程修改结构（如
addFirst()导致扩容），下次next()会立即抛ConcurrentModificationException - 单线程下也要小心：在 for-each 循环里调用
removeLast()会触发异常，应改用while(!deque.isEmpty()) { deque.removeFirst(); }或显式迭代器 +remove()
缓存局部性不是玄学，它就藏在数组是否连续、访问是否顺序、分支是否可预测里。ArrayDeque 把这三点都做对了，但前提是别把它当 LinkedList 用，也别忽略容量规划和 null 约束——这些细节一松动，性能优势就从根上瓦解。
