哪些集合类是线程安全的？

线程安全的集合类是指在多线程环境下能保证数据一致性和完整性的集合，java中主要包括vector、hashtable、collections.synchronizedxxx包装集合以及java.util.concurrent包下的并发集合。1. vector和hashtable通过方法级别的synchronized实现线程安全，但性能较差；2. collections.synchronizedxxx提供对非线程安全集合的同步包装，但复合操作仍需外部同步；3. java.util.concurrent包中的concurrenthashmap、copyonwritearraylist、concurrentlinkedqueue等采用分段锁、cas、写时复制等机制，适合高并发场景。适用场景方面，concurrenthashmap适用于高并发map操作，copyonwritearraylist适合读多写少，concurrentlinkedqueue适合高性能非阻塞队列，blockingqueue适合生产者-消费者模型。使用时需注意复合操作的原子性、迭代器行为差异、性能开销及内存可见性问题。此外，结合不可变对象、线程封闭、原子变量、显式锁和并发工具类等策略，能更全面地应对并发编程挑战。

在多线程编程的语境下，提及“线程安全”的集合类，我们通常指的是那些在多个线程同时访问和修改时，能够保证数据一致性和完整性，避免出现竞态条件（race condition）的集合。核心上，Java标准库中提供这类功能的，包括早期的一些同步容器如

Vector

和

Hashtable

，以及通过

Collections.synchronizedXxx

方法包装的同步集合，但真正为高并发场景设计并优化的是

java.util.concurrent

包下的诸多并发集合，例如

ConcurrentHashMap

、

CopyOnWriteArrayList

和

ConcurrentLinkedQueue

等。

解决方案

要解决多线程环境下共享数据的问题，选择合适的线程安全集合是关键。

1. 遗留的同步容器：

Vector

Hashtable

这俩算是Java集合框架里的“老兵”了。它们之所以线程安全，是因为其内部的每个公共方法都使用了

synchronized

关键字进行同步。这意味着在任何给定时间，只有一个线程能够访问这些集合的任何方法。这种粗粒度的锁机制虽然保证了线程安全，但也带来了显著的性能开销，尤其是在高并发读写场景下，所有操作都必须等待锁释放，效率非常低下。我个人在新的项目里几乎不会主动选择它们，除非是维护老代码，或者某些极端简单的场景，对性能完全不敏感。

2. 包装器模式：

Collections.synchronizedList/Map/Set

Collections

工具类提供了一系列静态方法，可以将非线程安全的集合（如

ArrayList

、

HashMap

、

HashSet

）包装成线程安全的版本。例如，

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

。它的实现原理和

Vector

/

Hashtable

类似，也是通过在每个方法上加

synchronized

锁来实现。但这里有个大坑：虽然单个操作（如

add

、

get

、

remove

）是线程安全的，但涉及多个操作的复合操作（例如“如果不存在则添加”：

if (!list.contains(element)) list.add(element);

）却仍然不是原子性的。这种情况下，你仍然需要外部的同步机制来保证整个复合操作的原子性，这无疑增加了使用的复杂性。

3. 高并发的利器：

java.util.concurrent

包

这才是现代Java并发编程的真正舞台。这个包里的集合类是专门为并发环境设计的，它们采用了更高级、更细粒度的同步策略，如分段锁（早期

ConcurrentHashMap

）、CAS（Compare-And-Swap）操作、写时复制（Copy-On-Write）等，大大提升了并发性能。

• ConcurrentHashMap

  : 这是线程安全Map的首选。它不是通过对整个Map加锁，而是通过更精妙的机制（在Java 7及以前是分段锁，Java 8及以后是CAS和Node级别的锁）来实现高并发读写。读操作通常是非阻塞的，写操作也只锁定修改的部分，性能表现卓越。我几乎所有需要线程安全Map的地方都会优先考虑它。

• CopyOnWriteArrayList

  和

  CopyOnWriteArraySet

  : 这两种集合的特点是“写时复制”。当有修改操作（如

  add

  、

  set

  、

  remove

  ）发生时，它们会复制底层数组，在新数组上进行修改，然后将引用指向新数组。读操作则直接在旧数组上进行，无需加锁。这种机制非常适合读多写少的场景，例如维护一个监听器列表或者配置信息。缺点也很明显：每次写入都会复制整个数组，内存开销和CPU开销都比较大；同时，迭代器看到的是一个快照，不会反映迭代过程中发生的修改。

• ConcurrentLinkedQueue

  和

  ConcurrentLinkedDeque

  : 非阻塞的线程安全队列。它们基于链表结构，通过CAS操作实现无锁的并发访问。在需要高吞吐量的生产者-消费者模型中，它们是非常好的选择，因为它们避免了锁的开销。

• ConcurrentSkipListMap

  和

  ConcurrentSkipListSet

  : 基于跳表（Skip List）实现的并发有序Map和Set。它们提供了O(log n)的平均时间复杂度，并且在并发环境下表现出色，因为跳表的结构允许并发操作在不同的“层”上进行，减少了冲突。如果你需要一个线程安全的、并且需要保持元素有序的集合，它们是比

  Collections.synchronizedSortedMap/Set

  更好的选择。

• BlockingQueue

  接口及其实现类（如

  ArrayBlockingQueue

  ,

  LinkedBlockingQueue

  ,

  SynchronousQueue

  等）: 虽然它们不是通用的“集合”，但在并发编程中扮演着至关重要的角色，尤其是在生产者-消费者模式中。它们支持阻塞式的插入和移除操作，是线程间协作的强大工具。

为什么我们还需要线程安全的集合类，以及它们各自的适用场景是什么？

在多线程应用程序中，多个执行流（线程）可能同时访问和修改同一个共享的数据结构。如果没有适当的同步机制，就会出现各种各样的问题，比如数据丢失、数据不一致、程序崩溃等，这些都是所谓的“竞态条件”。举个例子，如果两个线程同时尝试往一个普通的

ArrayList

里添加元素，它们可能会覆盖彼此的写入，或者导致内部状态损坏。所以，线程安全的集合类就是为了解决这些问题而生的，它们通过内部的同步机制，确保在并发访问下数据操作的原子性、可见性和有序性。

至于它们的适用场景，其实我在上面解决方案里已经带了一些个人看法，这里再总结一下：

• Vector

  和

  Hashtable

  : 几乎是历史遗留问题。在现代Java开发中，除非你必须兼容非常老的代码库，否则不推荐使用。它们的全局锁机制在高并发下性能表现糟糕。

• Collections.synchronizedXxx

  : 适用于对并发性能要求不高，或者需要将现有非线程安全集合“临时”包装成线程安全的场景。记住，它仅仅是方法级别的同步，复合操作依然需要外部同步。如果你只是偶尔需要一个线程安全的列表，且不涉及复杂的并发逻辑，它能用，但不是最优解。

• ConcurrentHashMap

  : 这是最常用的线程安全Map，几乎是所有需要并发Map的场景的首选。无论是缓存、统计、或者任何需要高效并发读写的键值存储，它都是不二之选。它的设计考虑了高并发下的性能优化，使得读操作通常是非阻塞的，写操作也能以较细粒度进行。

• CopyOnWriteArrayList

  /

  CopyOnWriteArraySet

  : 特别适合那种“读多写少”的场景。比如，一个事件监听器列表，大多数时候是遍历调用监听器，很少会增删监听器。或者一个应用程序的配置列表，初始化后很少变动，但会被频繁读取。它的优点在于读操作完全无锁，性能极高；缺点是写操作成本高，并且迭代器提供的是一个“快照”，不能反映实时变化。

• ConcurrentLinkedQueue

  /

  Deque

  : 适用于需要高性能、非阻塞队列的场景，例如实现一个消息队列、任务调度队列。它们通过无锁算法实现，避免了传统锁带来的上下文切换和死锁风险，在高并发生产者-消费者模式中表现优异。

• BlockingQueue

  及其实现类: 当你需要线程间进行协调，例如一个线程生产数据，另一个线程消费数据时，阻塞队列是最佳选择。它们提供了阻塞式的

  put

  和

  take

  方法，简化了线程间的同步逻辑，避免了手动实现复杂的等待/通知机制。

使用线程安全的集合类时，有哪些常见的“陷阱”或需要注意的性能考量？

即便使用了线程安全的集合类，也并不意味着你的并发程序就万无一失了。很多时候，坑就藏在那些看似简单的操作背后。

首先，最常见也是最容易犯的错误就是复合操作的非原子性。我前面提到了

Collections.synchronizedXxx

的例子，比如

if (!map.containsKey(key)) map.put(key, value);

。即使

containsKey

和

put

各自是线程安全的，但这两个操作合在一起就不是了。在多线程环境下，一个线程检查

containsKey

返回

false

后，另一个线程可能立即

put

进去，导致第一个线程再

put

时覆盖了数据，或者出现重复。解决这个问题，要么使用集合自身提供的原子性方法（如

ConcurrentHashMap

的

putIfAbsent

），要么就得手动添加外部同步锁（比如

synchronized (myMap)

）。

其次，是性能考量。虽然

ConcurrentHashMap

等并发集合比

Vector

/

Hashtable

性能好得多，但它们仍然有开销。

synchronized

关键字的开销是显而易见的，即使是

ConcurrentHashMap

内部的细粒度锁，在极端高并发和高竞争的情况下，也可能成为瓶颈。

CopyOnWriteArrayList

在写操作时的性能开销尤其大，因为它涉及数组的复制。如果你在一个写操作非常频繁的场景使用了它，那简直是给自己挖了个大坑。所以，选择合适的集合类，必须基于对应用程序读写模式的深刻理解。

再来，迭代器的行为差异也值得注意。

• Vector

  和

  Hashtable

  的迭代器是fail-fast的。这意味着如果你在迭代过程中，有其他线程修改了集合，迭代器会立即抛出

  ConcurrentModificationException

  。这在调试时很有用，因为它能帮你发现并发问题，但在生产环境中可能导致程序崩溃。

• ConcurrentHashMap

  的迭代器是弱一致性（weakly consistent）的。它不会抛出

  ConcurrentModificationException

  ，但它可能不反映迭代器创建后发生的所有修改，也就是说，你看到的可能是旧数据或者部分新数据。它提供的是一种“足够好”的一致性，满足大多数并发场景的需求。

• CopyOnWriteArrayList

  的迭代器则看到的是一个快照（snapshot）。它在迭代器创建时，底层数组已经被复制了一份，所以无论后续集合如何修改，迭代器都只会遍历那个固定不变的快照。这使得它永远不会抛出

  ConcurrentModificationException

  ，但代价是看不到实时更新。

最后，一个微妙但重要的点是内存可见性。虽然线程安全的集合类会处理内部数据的可见性问题，但如果你将从集合中取出的对象进行修改，而这个对象本身不是线程安全的，那么这些修改的可见性就需要你额外关注。例如，你从

ConcurrentHashMap

中取出一个自定义的

MyObject

实例，然后修改

MyObject

的某个非

volatile

字段，其他线程可能无法立即看到这个修改。这通常需要你确保存储在集合中的对象本身是不可变的，或者其内部状态的变化也能被正确同步。

除了直接使用线程安全的集合，还有哪些设计模式或策略可以帮助我们处理并发访问共享数据的问题？

仅仅依赖线程安全的集合类，很多时候是不够的。并发编程的复杂性远不止于此，它需要一套组合拳。除了使用内置的线程安全集合，我们还有多种设计模式和策略来应对并发挑战：

1. 不可变对象（Immutable Objects）：这是处理共享数据最简单也最有效的方式之一。如果一个对象在创建后其状态就不能再被修改，那么它就是天然线程安全的。多个线程可以安全地共享和访问它，无需任何同步措施。Java中的

   String

   、

   Integer

   等包装类就是典型的不可变对象。当你设计自己的类时，如果可能，尽量将其设计成不可变的，这能极大地简化并发编程。

2. 线程封闭（Thread Confinement）/ 线程局部存储（ThreadLocal）：如果数据只在单个线程内部使用，不被其他线程共享，那么它自然就是线程安全的。这种策略称为线程封闭。

   ThreadLocal

   就是实现线程封闭的一种常用机制，它为每个线程提供了一个独立的变量副本。每个线程操作的都是自己的副本，互不干扰，从而避免了共享数据带来的同步问题。我个人在处理一些线程特定上下文信息时，比如用户会话、事务ID等，经常会用到

   ThreadLocal

   。

3. 原子变量（Atomic Variables）：

   java.util.concurrent.atomic

   包提供了一系列原子类，如

   AtomicInteger

   、

   AtomicLong

   、

   AtomicReference

   等。这些类通过底层硬件支持的CAS（Compare-And-Swap）操作来实现无锁的原子性操作。它们比使用

   synchronized

   关键字具有更细粒度的控制和更好的性能，特别适合于对单个变量进行原子更新的场景，比如计数器或者状态标志。

4. 显式锁（Explicit Locks）：

   java.util.concurrent.locks

   包提供了比

   synchronized

   关键字更强大、更灵活的锁机制，例如

   ReentrantLock

   、

   ReentrantReadWriteLock

   。

   • ReentrantLock

     提供了与

     synchronized

     类似的功能，但它提供了更多高级特性，比如尝试非阻塞地获取锁（

     tryLock()

     ）、可中断的锁获取（

     lockInterruptibly()

     ）以及公平锁模式。

   • ReentrantReadWriteLock

     则更进一步，它允许多个读线程同时访问共享资源（读锁），但写操作（写锁）是排他的。这对于读多写少的场景非常有效，可以显著提高并发性能。当你发现

     synchronized

     的粗粒度无法满足需求时，可以考虑这些显式锁。

5. 并发工具类（Concurrency Utilities）：

   java.util.concurrent

   包不仅仅提供了集合和锁，还有许多高级的并发工具，它们能够帮助你更好地协调和管理线程：

   • 执行器框架（Executor Framework）：如

     ThreadPoolExecutor

     ，用于管理线程池，将任务的提交与执行解耦，避免了频繁创建和销毁线程的开销，并能限制并发线程的数量。

   • 信号量（Semaphore）：用于控制对某个资源的并发访问数量，比如限制同时访问数据库连接的线程数。
   • 栅栏（CyclicBarrier）和闭锁（CountDownLatch）：用于线程间的同步协调。

     CountDownLatch

     让一个或多个线程等待其他线程完成操作，而

     CyclicBarrier

     则让一组线程互相等待，直到所有线程都到达一个共同的屏障点。

   • Future 和 CompletableFuture：用于异步编程，处理并发任务的结果，以及任务间的依赖关系。

这些模式和工具并非相互独立，而是可以组合使用的。在实际项目中，往往需要根据具体的业务场景、性能要求和代码复杂性，灵活选择和搭配这些策略。并发编程没有银弹，理解每种工具的优缺点和适用场景，是写出健壮、高效并发代码的关键。