Java线程安全集合演进路径为“粗粒度锁→按需同步→无锁/分段锁”：Vector/Hashtable是JDK1.0自带全方法synchronized的默认安全类；Collections.synchronizedCollection是JDK1.2起基于装饰器模式的可选加锁方案，支持自定义锁对象与统一接口；二者均因全局锁性能差、迭代器需手动同步等缺陷，被JUC并发集合取代。
Java 中的线程安全集合演进，本质是一条“从粗粒度锁到按需同步、再到无锁/分段锁”的技术路径。Collections.synchronizedCollection 和 Vector/Hashtable 并非并列替代关系，而是不同阶段的设计产物：Vector 和 Hashtable 是 JDK 1.0 就存在的“自带锁”类；Collections.synchronizedXXX 是 JDK 1.2 引入的通用包装方案；而 synchronizedCollection 正是这一包装体系中面向 Collection 接口的统一入口。
历史定位：从“默认加锁”到“可选加锁”
Vector 和 Hashtable 出生于 Java 初期（1996 年 JDK 1.0），设计目标是“开箱即用的安全”。它们所有公有方法（add、get、put、remove 等）都直接用 synchronized 修饰，锁的是整个对象实例。这种“一刀切”的线程安全，对单线程场景造成显著性能损耗——实测吞吐量比非同步版本低 30% 以上。
Collections.synchronizedCollection（以及配套的 synchronizedList、synchronizedMap 等）诞生于 JDK 1.2（1998 年），是 Java 集合框架（JCF）统一化的重要一环。它不提供新容器实现，而是通过装饰器模式，把任意非线程安全集合（如 ArrayList、HashSet、HashMap）“套一层同步壳”。关键改进在于：
- 锁对象可指定：默认使用集合自身作为 mutex，但允许传入自定义 lock 对象，便于细粒度控制
- 接口统一：所有 Collection 子类型都能被同等包装，避免了 Vector/List、Hashtable/Map 的割裂
- 明确权责：线程安全不再是容器的固有属性，而是由使用者按需赋予
性能表现：锁粒度决定实际开销
两者都是重量级同步，但实现细节导致实际表现有差异：
立即学习“Java免费学习笔记（深入）”；
- Vector/Hashtable：每个方法内部隐式使用 this 锁，方法调用链长时（比如 removeElementAt 涉及查找+移动），锁持有时间不可控；且扩容、遍历等操作也全程持锁，容易成为瓶颈
- Collections.synchronizedCollection：同步块仅包裹目标方法调用，逻辑更干净；但若底层集合本身效率低（如 ArrayList 在中间插入），同步开销会叠加在原有成本上
- 共同短板：迭代器仍需手动同步。例如：
for (Object o : syncList) { ... }不是原子操作，必须外层加 synchronized 块，否则可能抛 ConcurrentModificationException
为什么现在基本不用它们？
不是因为写错了，而是场景变了：
- 绝大多数业务代码运行在单线程上下文（如 Web 请求线程、定时任务线程），根本不需要同步，ArrayList + HashMap 更轻快
- 真有并发读写需求时，Vector/Hashtable 和 synchronizedXXX 的全局锁成了性能天花板，尤其在高并发读场景下
- JUC 提供了更优解：ConcurrentHashMap 支持高并发读、分段/跳表写；CopyOnWriteArrayList 适合读多写少的监听列表；BlockingQueue 天然适配生产者-消费者模型
- 现代开发强调“组合优于继承”，synchronizedCollection 这种包装方式更灵活，但 Vector 继承自 AbstractList 又加锁，语义混杂，不利于维护
实际选型建议
除非维护老系统，否则不推荐主动选用：
- 新项目：优先考虑 ConcurrentHashMap、ConcurrentLinkedQueue、CopyOnWriteArrayList 等 JUC 类
- 需要快速将现有 ArrayList 转为线程安全：用
Collections.synchronizedList(new ArrayList())比改用 Vector 更清晰，语义上表明“这是临时加锁，非设计本意” - 仅作简单计数或状态缓存：AtomicInteger、AtomicReference 等原子类比加锁集合更高效
- 若必须用传统同步集合：注意所有复合操作（如“检查再插入”）仍需额外同步，synchronizedCollection 不提供原子性保障
