Vector性能差因同步锁粗粒度：单线程浪费开销，多线程争抢同一锁，复合操作仍不安全；Stack同理且API陈旧、不兼容Deque，LIFO场景应改用ArrayDeque。
Vector 为什么性能差？同步锁不是万能药
Vector 所有公共方法（add、get、remove、size）都加了 synchronized，看似线程安全，实则代价巨大：
- 单线程下纯属浪费：每次调用都要走锁流程，JVM 即便做锁消除，也不保证生效
- 多线程下锁太粗：哪怕线程 A 读首元素、线程 B 加尾元素，也得抢同一把对象锁，吞吐量骤降
- 复合操作仍不安全：比如
if (!v.isEmpty()) v.get(0)，两步之间可能被其他线程清空，照样抛ArrayIndexOutOfBoundsException
这不是“安全换慢”，而是“假安全 + 真拖慢”。
ArrayList 是 Vector 的直接替代，但要注意线程场景
绝大多数业务代码根本不需要 Vector 级别的同步——你真正需要的，是明确控制同步边界：
- 单线程或容器只在局部使用 → 直接用
ArrayList，性能提升明显 - 需要简单包装的线程安全 → 用
Collections.synchronizedList(new ArrayList())，注意：它的iterator()仍需手动加锁 - 读远多于写 → 改用
CopyOnWriteArrayList，避免读操作阻塞 - 高并发+复杂操作 → 跳过 List，直接上
ConcurrentLinkedQueue或ConcurrentHashMap
Listlist = new ArrayList<>(); // ✅ 默认首选 List syncList = Collections.synchronizedList(new ArrayList<>()); // ⚠️ 同步仅限单方法 synchronized (syncList) { if (!syncList.isEmpty()) { String first = syncList.get(0); // ✅ 复合操作必须包在 synchronized 块里 } }
Stack 为何不能用？LIFO 场景该选什么
Stack 是 Vector 的子类，继承了全部缺陷，还额外绑死 LIFO 行为。它没被 @Deprecated，但文档明写“do not use”：
立即学习“Java免费学习笔记（深入）”；
- 继承自 Vector → 同样同步开销大、扩容激进（翻倍）、API 陈旧（
push/pop之外还有addElement这种怪胎） - 不实现
Deque接口 → 无法与现代队列工具（如ArrayDeque）互换，替换成本高 - 增强 for 循环不支持：
for (E e : stack)编译失败，因为没实现Iterable
LIFO 场景请统一用 Deque 接口：
Dequestack = new ArrayDeque<>(); // ✅ 推荐：高性能、无同步、接口标准 stack.addLast(1); stack.addLast(2); Integer top = stack.pollLast(); // 相当于 pop // 想换链表实现？只需改一行： // Deque stack = new LinkedList<>(); // ✅ 其他 150 处调用完全不用动
遗留代码里遇到 Vector/Stack，怎么安全迁移
老项目里搜出 Vector 或 Stack，别急着全局替换，先看实际用途：
- 只在单线程初始化后当普通列表用 → 替换为
ArrayList或Arrays.asList(...) - 用到了
elements()或elementAt()→ 改成iterator()或get()，并检查是否允许null - 用
Stack做函数调用栈或 DFS → 必须换成ArrayDeque，它比LinkedList更快且内存更紧凑 - 真有跨方法共享的并发写需求 → 不要修修补补，直接重构为
ConcurrentLinkedDeque或加显式锁
最容易被忽略的一点：Vector 的 capacityIncrement 和扩容逻辑（翻倍）在 ArrayList 中不存在，迁移后如果出现 OOM 或频繁扩容，得检查初始容量是否合理设置。
