Vector和Stack因同步锁、低效扩容及过时设计已被淘汰，应按场景选用ArrayList、CopyOnWriteArrayList、ArrayDeque等现代替代方案。
Vector 的 synchronized 方法是性能瓶颈的根源
Vector 几乎所有公开方法（add、get、remove、size）都加了 synchronized，意味着每次调用都要获取对象锁。这不是“细粒度同步”，而是整把大锁——哪怕你只是读一个元素，也要排队等锁释放。
- 单线程下纯属冗余开销：没有并发竞争，却强制走锁机制，上下文切换+JVM同步原语拖慢执行速度
- 高并发时更糟：多个线程争同一把锁，变成串行化操作，吞吐量卡在单核水平
- 无法规避：你不能只对写操作加锁、读操作不加——Vector 没提供这种控制权
对比 ArrayList + Collections.synchronizedList()，后者至少允许你手动包裹临界区；而 Vector 把锁焊死在每个方法里，毫无灵活性。
扩容策略浪费内存且不可控
Vector 默认扩容是「翻倍」（oldCapacity * 2），而 ArrayList 是「1.5 倍」。假设初始容量 10，插入第 11 个元素时：
-
Vector→ 分配 20 个 slot，实际只用 11 个，闲置 9 个 -
ArrayList→ 分配 15 个 slot，闲置 4 个，更紧凑
更关键的是：Vector 的扩容增量（capacityIncrement）虽可设，但一旦设为 0，就退化为纯翻倍逻辑；而 ArrayList 的增长因子固定且经过大量实践验证，平衡了扩容频次与空间利用率。
立即学习“Java免费学习笔记（深入）”；
Stack 继承 Vector 导致双重过时
Stack 不是独立设计的栈，而是直接继承 Vector，所以它天然携带全部 Vector 缺陷：同步锁、翻倍扩容、枚举器（Enumeration）接口、非标准方法命名（如 push/pop 虽然语义清晰，但底层仍是 insertElementAt 和 removeElementAt 这类低效操作）。
- 它不支持现代集合遍历方式（增强 for 循环会报错，因未正确实现
Iterable） - 它的
search方法从栈底开始线性扫描，时间复杂度 O(n)，不是栈应有的行为 - 官方文档明确建议用
Deque替代，例如ArrayDeque（无锁、数组实现、push/pop接口一致）
Dequestack = new ArrayDeque<>(); stack.push("A"); stack.push("B"); System.out.println(stack.pop()); // B
替代方案不是“选一个”，而是“按场景选”
没有万能替代品，关键是匹配使用场景：
- 单线程、需要动态数组 → 直接用
ArrayList（轻量、快、API 清晰） - 需要线程安全且读多写少 →
CopyOnWriteArrayList（写时复制，读完全无锁） - 需要线程安全且写操作频繁 →
ConcurrentLinkedQueue或LinkedBlockingDeque（基于 CAS 的无锁/阻塞队列） - 仅需栈语义（LIFO）→
ArrayDeque（推荐默认）或LinkedBlockingDeque（需线程安全时）
真正容易被忽略的一点：Vector 和 Stack 仍存在于 JDK 中，不是因为它们还“可用”，而是为了兼容 20 多年前的老代码。你在新项目里看到它们，大概率是历史包袱，不是设计选择。
