首先需要澄清一个关键事实：JDK11 并没有移除 Vector 类，它仍然存在于 java.util 包中，只是被标记为不推荐使用（Deprecated）。现代开发应优先选择 ArrayList 配合线程安全包装或并发集合类作为替代方案。

背景与兼容性说明

Vector 类诞生于 JDK1.0，那时 Java 还没有系统的集合框架。到 JDK1.2 引入集合框架后，Vector 被改造为 List 接口的实现之一，但设计上的历史包袱无法彻底清理。

不推荐使用的核心原因有三点：第一，Vector 所有公共方法都使用 synchronized 修饰，单线程场景下纯属性能浪费，多线程下粗粒度锁又会导致争抢严重；第二，复合操作如“先检查是否为空再获取元素”仍然不安全，因为两步之间可能被其他线程修改；第三，API 设计陈旧，保留了已废弃的 Enumeration 接口和 addElement() 等冗余方法。

Oracle 官方文档从未宣布在 JDK11 移除 Vector，出于向后兼容性考虑它一直保留至今，但官方文档和主流技术社区都明确建议避免在新代码中使用。

分步处理

第一步：扫描现有代码

在项目中搜索 Vector 和 Stack 的使用位置：

grep -r "import java.util.Vector" src/
grep -r "new Vector" src/
grep -r "import java.util.Stack" src/

记录每个使用点的上下文，判断是否真的需要线程安全。

第二步：按场景选择替代方案

单线程场景，直接替换为 ArrayList：

// 原代码
Vector<String> vector = new Vector<>();

// 替换后
List<String> list = new ArrayList<>();

需要线程安全且写多读少，使用 Collections.synchronizedList：

List<String> list = Collections.synchronizedList(new ArrayList<>());

读多写少的并发场景，使用 CopyOnWriteArrayList：

List<String> list = new CopyOnWriteArrayList<>();

栈结构需求，用 ArrayDeque 替代 Stack：

// 原代码
Stack<Integer> stack = new Stack<>();

// 替换后
Deque<Integer> stack = new ArrayDeque<>();

第三步：处理复合操作的线程安全问题

Vector 看似线程安全，但以下代码仍有风险：

// 不安全：两步之间可能被其他线程修改
if (!vector.isEmpty()) {
    vector.get(0);
}

替换为 synchronizedList 后，需要手动同步复合操作：

List<String> list = Collections.synchronizedList(new ArrayList<>());
synchronized(list) {
    if (!list.isEmpty()) {
        list.get(0);
    }
}

第四步：更新迭代方式

将 Enumeration 替换为 Iterator 或增强 for 循环：

// 原代码（已过时）
Enumeration<String> e = vector.elements();
while (e.hasMoreElements()) {
    String s = e.nextElement();
}

// 替换后
for (String s : list) {
    // 处理元素
}

怎么验证是否生效

1. 编译检查

重构后执行构建命令，确认没有编译错误：

mvn clean compile
# 或
gradle build

2. 静态代码分析

使用 IDE 的 Inspection 功能或静态分析工具（如 SonarQube）检查是否还有 Vector/Stack 的遗留引用。配置规则忽略“过时 API 使用”警告，确认重构完成。

3. 单元测试回归

运行原有测试用例，确保功能行为一致。重点关注涉及并发操作的测试用例，必要时增加并发压力测试。

4. 运行时监控

上线后观察应用日志，确认没有 ClassNotFoundException 或 NoSuchMethodError 等异常，监控 GC 频率和锁竞争情况是否有改善。

常见坑

坑一：以为替换后就完全线程安全

Collections.synchronizedList 只保证单个方法调用安全，复合操作仍需手动同步。如果原代码依赖 Vector 的“伪安全”，替换后可能暴露并发问题。

坑二：Stack 替换时忽略接口差异

Stack 继承 Vector，暴露了 setElementAt() 等破坏 LIFO 原则的方法。ArrayDeque 作为 Deque 实现，接口不同，需要调整调用方式。

坑三：序列化兼容性

如果 Vector 对象需要序列化存储或跨版本传输，替换为 ArrayList 后可能影响反序列化兼容性，需评估数据持久化场景。

坑四：遗留系统依赖

某些第三方库或旧框架可能内部使用 Vector，强行替换可能引发兼容问题。先确认依赖链，必要时保留 Vector 仅在新代码中避免使用。

参考来源

• Oracle Official Documentation - java.util.Vector Class, https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/Vector.html
• Oracle Official Documentation - java.util.Collections Class, https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/Collections.html
• Java Concurrency in Practice - Brian Goetz (Regarding synchronized collections vs concurrent collections)