vector因粗粒度同步、僵化扩容和接口越界等缺陷，已不适用于现代并发场景；应依场景选用arraylist、copyonwritearraylist或concurrentlinkedqueue等更优替代方案。
vector 是理解 java 早期线程安全集合设计逻辑的一把钥匙，但它本身恰恰暴露了那种“一刀切同步”思路的深层缺陷。它不是错在功能，而是在性能模型、封装边界和演进适应性上，已跟不上现代并发场景的真实需求。
同步粒度太粗，锁住的是整个对象，不是操作意图
Vector 所有 public 方法（add、get、remove、size、isEmpty 等）都用 synchronized 锁住 this。这意味着：
- 单线程调用 get(i) 也要走锁流程，纯属冗余开销
- 两个线程分别读首元素和写末尾元素，仍被迫串行——实际并无数据竞争
- 无法通过外部 synchronized 块优化，因为锁已被方法内部独占
扩容策略僵化，内存与性能双失衡
默认初始容量 10，扩容直接翻倍（10→20→40→80…），对比 ArrayList 的 1.5 倍（10→15→22→33…）：
- 小量增长时内存浪费明显，比如只加 12 个元素就占了 20 个槽位
- 大容量下一次扩容拷贝成本陡增，且无法预测抖动点
- capacityIncrement 虽可定制，但极少被正确使用，多数人依赖默认行为
接口陈旧且语义越界，违背封装原则
Vector 不仅实现 List，还保留 Enumeration、elementAt()、insertElementAt() 等 JDK 1.0 遗留 API：
- Enumeration 不支持删除，也无法用于 for-each 循环
- Stack 继承 Vector 后，既暴露 push/pop，又暴露 removeElementAt()，LIFO 栈语义被彻底破坏
- 它名义上是“列表”，却承担队列、栈、甚至老式枚举器的多重角色，职责不清
真正线程安全？复合操作照样出错
方法级同步 ≠ 业务逻辑原子性。典型竞态代码：
if (!v.isEmpty()) {
v.get(0); // 中间可能被其他线程清空
}
这种“先检查后执行”（check-then-act）模式，在 Vector 中依然不安全。官方也明确指出：它无法保障多步组合操作的一致性。
现代替代方案按需选择，不再妥协
没有银弹，只有适配场景的合理选型：
- 单线程高频访问：直接用 ArrayList，零同步成本，随机访问快
- 读多写少 + 线程安全：CopyOnWriteArrayList，读完全无锁，适合监听器列表等场景
- 通用线程安全列表：Collections.synchronizedList(new ArrayList())，至少比 Vector 更灵活（可自定义底层数组）
- 栈结构：ArrayDeque（非线程安全，但 push/pop/peek 接口标准、性能最优）；需要并发时用 ConcurrentLinkedDeque
- 高吞吐队列：ConcurrentLinkedQueue 或 LinkedBlockingQueue，而非 Vector 兼容的遗留队列模拟
Vector 的价值，今天主要在教学和兼容性层面——它让我们看清，用全局锁换线程安全，是一条走不通的窄路。现代方案不是放弃安全，而是用更细的控制、更准的抽象、更轻的代价去实现它。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
