arraystack扩容拖慢push操作是因为满时需新建数组并复制全部元素，使单次push从o(1)退化为o(n)；默认容量16易触发频繁翻倍扩容，导致耗时骤增和gc压力。
ArrayStack 的扩容机制怎么拖慢 push 操作
ArrayStack（比如 java.util.ArrayDeque 被误用作栈时）本质是数组，push 在满时触发扩容——不是简单加一，而是新建数组、复制全部元素。这导致单次 push 从 O(1) 退化为 O(n)，尤其在反复 push 到临界点时，抖动明显。
常见错误现象：ArrayDeque 在压入 10 万元素过程中，耗时突然跳升 5–10 倍，GC 日志里频繁出现 Allocation Failure。
- 避免预估不准：别依赖默认初始容量（
ArrayDeque默认是 16），用带参构造函数显式指定new ArrayDeque(expectedMaxSize) - 扩容因子不可调：JDK 源码里是翻倍增长（
newCapacity = oldCapacity ），无法通过配置修改 - 如果压栈深度稳定可预期，
ArrayDeque配合预分配，实际性能通常优于链表栈
LinkedStack 实际用的是什么结构
Java 标准库没有叫 LinkedStack 的类，开发者常指手写基于 Node 的单链表栈，或误把 java.util.Stack（继承自 Vector）当链表栈——它其实是同步数组栈，性能更差。
真正链表栈的 push 和 pop 是严格 O(1)，无扩容开销，但每次操作都要 new 一个 Node 对象。
立即学习“Java免费学习笔记（深入）”；
- 对象分配成本高：小对象频繁创建会加重 GC 压力，尤其在 G1 或 ZGC 下可能触发年轻代频繁回收
- 内存不连续：节点散落在堆各处，CPU 缓存命中率低，大量
pop连续读取时，比ArrayDeque多出数倍 cache miss - 如果栈深波动大、上限不可知，且单次操作延迟敏感（如实时风控校验），链表栈更稳
为什么 ArrayDeque 比 Stack 快得多
java.util.Stack 是遗留类，继承 Vector，所有方法加了 synchronized；而 ArrayDeque 不仅无锁、数组连续，还把栈顶放在索引高位（head 和 tail 双端维护），push 直接写 elements[tail++]。
实测压入 100 万个整数：Stack 比 ArrayDeque 慢 3–5 倍，且线程越多，同步瓶颈越明显。
- 永远别用
Stack：它不是“链表栈”，也不是现代栈实现，只是历史包袱 -
ArrayDeque的push/pop对应addLast/removeLast，语义清晰，JIT 也更容易优化 - 注意：它不允许 null 元素，插入 null 会抛
NullPointerException，而Stack允许——这是隐性兼容断层
内存连续性到底影响哪些操作
连续性不只关乎“快”，更决定访问模式是否友好。ArrayDeque 的元素挤在一段内存里，for-each 遍历栈内全部剩余元素（比如 debug 打印或批量处理）时，速度可能是链表栈的 8–10 倍；但若只做单次 peek，差异几乎不可测。
- GC 友好：大块连续内存便于 G1 的 region 整理，而百万级链表节点会让 GC root 枚举变慢
- 序列化开销低：ArrayDeque 底层数组可直接
System.arraycopy复制，链表栈要递归遍历序列化每个Node - 容易被忽略的一点：ArrayDeque 的
size()是 O(1)，而手写链表栈若没缓存 size 字段，size()是 O(n)
