Java中Vector为何不推荐使用？历史集合类解析

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 的增长因子固定且经过大量实践验证，平衡了扩容频次与空间利用率。

Stack 继承 Vector 导致双重过时

Stack 不是独立设计的栈，而是直接继承 Vector，所以它天然携带全部 Vector 缺陷：同步锁、翻倍扩容、枚举器（Enumeration）接口、非标准方法命名（如 push/pop 虽然语义清晰，但底层仍是 insertElementAt 和 removeElementAt 这类低效操作）。

• 它不支持现代集合遍历方式（增强 for 循环会报错，因未正确实现 Iterable）
• 它的 search 方法从栈底开始线性扫描，时间复杂度 O(n)，不是栈应有的行为
• 官方文档明确建议用 Deque 替代，例如 ArrayDeque（无锁、数组实现、push/pop 接口一致）

Deque<String> stack = 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 多年前的老代码。你在新项目里看到它们，大概率是历史包袱，不是设计选择。