Java 并发容器的演进历程是 Java 语言在多线程环境下追求性能与安全平衡的缩影。本文将针对 List、Set、Queue（含 Stack）以及 Map 的并发实现方案进行系统化总结，并深度剖析装饰器模式与 Legacy 类的原理差异及底层实现机制。
一、 并发容器实现方案的分类综述
Java 并发容器的演进主要遵循三条技术路线：早期遗留类（Legacy Classes） 、同步包装类（Synchronized Decorators）以及高性能并发工具类（JUC Utils）。
1. List 接口的并发实现
- Vector ：作为 JDK 1.0 的早期遗留实现，底层采用动态对象数组。其线程安全机制通过在所有公有方法（如
add、get、remove）上直接声明synchronized关键字实现。这种方法级的重量级锁导致了极高的锁竞争，目前已基本被废弃。 - Collections.synchronizedList ：基于装饰器模式实现。该方案通过一个包装类持有非线程安全的 List（如
ArrayList），并在方法内部使用synchronized(mutex)代码块进行同步，锁的控制权较Vector更具灵活性。 - CopyOnWriteArrayList ：
java.util.concurrent(JUC) 包下的现代工业标准。核心原理为"写时复制"（Copy-On-Write）结合volatile数组。在写操作时申请新内存并进行全量拷贝，而读操作完全无锁，适用于"读多写极少"的特定场景。
2. Set 接口的并发实现
由于 Set 的本质是键值对中 Value 为固定虚拟对象的 Map，JDK 未提供独立的 ConcurrentHashSet 类，而是通过以下方式实现：
- ConcurrentHashMap.newKeySet() ：基于
ConcurrentHashMap的键集合视图（KeySetView）实现。该方案继承了ConcurrentHashMap的 CAS 算法与细粒度锁优化，是目前高并发场景下的首选方案。 - CopyOnWriteArraySet ：底层依赖
CopyOnWriteArrayList。其特性与 COW 列表一致，适用于小规模数据且修改频率极低的场景。 - Collections.newSetFromMap() ：通过适配器模式，将任意线程安全的
Map（如ConcurrentHashMap）转换为对应的Set视图。
3. Queue 与 Stack 的并发实现
- Stack ：继承自
Vector的 LIFO 栈实现。由于继承了Vector的方法级同步锁，其并发性能受限，且因暴露了不符合栈定义的数组操作方法而存在设计缺陷。 - LinkedBlockingDeque ：基于双向链表和
ReentrantLock实现。利用 AQS 体系中的notEmpty和notFull条件变量实现阻塞机制，是生产者-消费者模型的经典实现。 - ConcurrentLinkedDeque：基于 CAS 算法实现的无锁并发双端队列，通过非阻塞算法（Wait-Free/Lock-Free）提供极高的吞吐量。
4. Map 接口的并发实现
- Hashtable ：JDK 1.0 遗留类，采用方法级
synchronized锁。其设计不仅性能较差，且在null值处理上具有严格限制。 - Collections.synchronizedMap ：装饰器模式实现，原理与
synchronizedList相同。 - ConcurrentHashMap：高性能 Map 的代表方案。经历从 JDK 7 的分段锁（Segment）到 JDK 8 及之后版本基于桶位锁（Node-level synchronization）与 CAS 的演进，大幅减小了锁粒度。
二、 Vector 与装饰器实现（SynchronizedList）的原理深度对比
对比 Vector 与 Collections.synchronizedList 的原理是理解 Java 集合演变逻辑的关键。
1. 继承模式（Inheritance） vs. 组合模式（Composition）
- Vector (继承模式) ：同步逻辑硬编码在类定义中，与具体的数据结构实现高度耦合。若需扩展功能，必须继承该类，这违反了"组合优于继承"的设计原则，导致了
Stack类等设计上的冗余与风险。 - SynchronizedList (装饰器模式) ：不改变原有的数据结构，通过组合方式持有原始
List的引用。这种模式实现了同步逻辑与业务逻辑的解耦，能够为任何List实现类（如ArrayList、LinkedList）动态赋予线程安全特性。
2. 锁对象的灵活性与控制权
- Vector 的内部锁 ：锁对象固定为
this（实例本身）。外部调用者无法干预同步策略，难以在不引入额外外部锁的情况下完成多步复合操作的原子化。 - 装饰器的 Mutex 锁 ：内部维护一个
final Object mutex对象。构造时允许显式指定外部对象作为锁。 - 应用优势 ：支持多操作原子化。通过让多个不同的包装类实例共享同一个
mutex对象，可以实现跨容器的同步控制，这是Vector无法实现的架构能力。
3. 锁粒度与 JVM 优化
Vector的方法级锁粒度最粗。相比之下，SynchronizedList的代码块级锁在语义上更精确。在现代 JVM 环境下，代码块级同步更易于被即时编译器（JIT）进行锁消除或锁粗化优化，从而在低竞争环境下表现出更优的性能。
三、 装饰器包装机制的底层逻辑
装饰器模式通过对原始容器的"封装"与"转发"，实现了对线程安全性的非侵入式增强。
1. 核心流程三部曲
- 持有引用（Composition） ：包装类（如
SynchronizedCollection）内部声明一个final Collection<E> c引用，指向被包装的原始非安全容器。final关键字确保了引用在多线程环境下的不可变性与初始化安全性。 - 设置同步锚点（Mutex） ：包装类内部持有
final Object mutex。该对象作为监视器锁（Monitor）的唯一标识，协调所有线程对底层容器的访问。 - 代理与转发（Delegation） ：包装类实现与原始容器相同的接口。在每个接口方法内部，首先竞争
mutex锁，获取锁后将业务逻辑委派给底层引用c执行。
2. 装饰器模式的安全风险：底层引用逸出
装饰器模式存在一个显著的局限性：如果用户在代码中同时保留了原始非安全容器 c 的直接引用和包装后的安全引用，并直接通过原始引用修改数据，装饰器的同步机制将失效。这种"底层引用逸出"会导致并发修改异常或数据不一致，属于开发中的高危操作。
3. 迭代器的线程安全性局限
装饰器的 iterator() 方法返回的是原始容器的迭代器，该迭代器并非同步实现。
- 风险 ：在遍历期间，若其他线程修改了容器结构，将触发 Fail-Fast 机制抛出
ConcurrentModificationException。 - 规避方案 ：在使用装饰器容器进行遍历时，必须在外部手动使用
synchronized(list)代码块，确保护持锁的范围覆盖整个遍历周期。
四、 总结与技术选型建议
Java 并发容器的演进体现了技术重心从"互斥锁保障安全"到"减小锁竞争提高性能"的转变。
- 传统开发：在低并发或简单的同步需求下，装饰器模式提供了一种低成本的适配手段。
- 高性能架构 ：在追求高吞吐量的工业级应用中，应优先选择基于 CAS（无锁化） 或 AQS 条件变量（精确阻塞） 的 JUC 专用容器。
- 架构选型准则：
- 读多写极少：
CopyOnWriteArrayList。 - 高频并发读写：
ConcurrentHashMap、ConcurrentLinkedDeque。 - 生产者-消费者模型：
LinkedBlockingDeque。
通过深度理解这些底层机制，开发者可以根据具体业务场景的负载特性，选择最匹配的并发模型，从而在保障数据一致性的前提下，实现系统吞吐量的最大化。