Vector和Stack被淘汰，核心是其粗粒度同步锁导致单线程性能低下、伪安全及API违背栈语义；现代替代方案按场景选用ArrayDeque、同步包装或Lock控制。
Vector 和 Stack 被淘汰，核心不是“不能用”，而是它们的线程安全实现方式在现代开发中成了性能拖累和设计负担。这种安全不是精细控制的结果，而是粗粒度、无差别、无法规避的同步锁强加给所有操作。
同步锁覆盖全部方法，单线程也逃不掉开销
Vector 的 add、get、size、remove 等所有公共方法都加了 synchronized。这意味着哪怕你在单线程里只读一个元素，JVM 仍要走 monitor 进入/退出流程——锁消除不一定生效，实际性能比 ArrayList 低一倍以上。Stack 继承 Vector，自然全盘继承这套机制，push/pop 也不例外。
- 没有“只读不锁”的路径：即使只是 peek() 查看栈顶，也要抢锁
- 无法做 JIT 优化：粗粒度锁让 JVM 难以判断是否可安全移除
- 伪安全：像
if (!stack.isEmpty()) stack.pop()这类复合操作，中间仍可能被其他线程干扰，照样抛异常
API 设计违背栈的本质语义
Stack 是 Vector 的子类，因此公开了 insertElementAt、removeAllElements、elementAt 等完全不属于栈行为的方法。这不仅破坏封装性，还让调用方误以为可以随意索引或批量修改——而这些操作会打乱 LIFO 逻辑，引发隐蔽 bug。
- search(Object) 方法暴露非栈语义，与“后进先出”无关
- 无法通过类型系统约束行为：声明为 Stack，却能调用 List 级别操作
- 官方 Javadoc 明确建议：“更完整、更一致的 LIFO 操作由 Deque 接口提供”
扩容机制与栈使用模式严重错配
Vector 默认扩容一倍（或按 capacityIncrement 增长），适合列表式追加；但 Stack 的典型场景是深度优先遍历、表达式解析等——元素增减频繁、幅度小、生命周期短。这种扩容策略容易造成内存抖动：刚分配的大数组很快被 pop 清空，又因下一次 push 再次触发扩容。
- 内存不可复用：pop 不释放底层数组空间，只减 size
- 高频率小规模操作下，实际内存占用远超必要值
- ArrayDeque 使用循环数组 + 指针移动，扩容更节制，空间利用率更高
现代替代方案不是简单“换类”，而是分场景选型
不再依赖“内置线程安全”的黑盒，而是按真实并发需求组合能力：
- 单线程高频栈操作 → ArrayDeque：无锁、O(1) push/pop、API 干净（push/pop/peek/isEmpty）
- 多线程且必须严格 LIFO → Collections.synchronizedCollection(new ArrayDeque())，或手动用 ReentrantLock 包裹关键段
- 读多写少的共享栈状态（如配置快照）→ 可考虑 CopyOnWriteArrayList，但注意写操作代价大，不适用于高频变更
- 遗留接口需兼容 → 至少把变量声明从
Stack<t></t>升级为Deque<t></t>，避免调用 Vector 特有方法
