如何保证集合是线程安全的?

典型回答

Java 提供了不同层⾯的线程安全支持。
- 在传统集合框架内部，除了 Hashtable 等同步容器，还提供了所谓的同步包装器（Synchronized Wrapper），我们可以调用 Collections 工具类提供的包装方法，来获取⼀个同步的包装容器（如 Collections.synchronizedMap），但是它们都是利用非常粗粒度的同步方式，在高并发情况下，性能比较低下。
- 普遍的选择是利用并发包提供的线程安全容器类：
  - 各种并发容器，比如 ConcurrentHashMap、CopyOnWriteArrayList。
  - 各种线程安全队列（Queue/Deque），如 ArrayBlockingQueue。
  - 各种有序容器的线程安全版本等。
- 具体保证线程安全的方式，包括有从简单的 synchronize 方式，到基于更加精细化的，比如基于分离锁实现的 ConcurrentHashMap 等并发实现等。

考点分析

谈到线程安全和并发，可以说是 Java 面试中必考的考点。
如果要深入思考并回答这个问题及其扩展方面，至少需要：
- 理解基本的线程安全工具。
- 理解传统集合框架并发编程中 Map 存在的问题，清楚简单同步方式的不足。
- 梳理并发包内，尤其是 ConcurrentHashMap 采取了哪些方法来提高并发表现。
- 最好能够掌握 ConcurrentHashMap 自身的演进。

知识扩展

为什么需要 ConcurrentHashMap？
- Hashtable 本身比较低效，因为它的实现基本就是将 put、get、size 等各种方法加上 “synchronized”。
- 简单来说，这就导致了所有并发操作都要竞争同⼀把锁，⼀个线程在进行同步操作时，其他线程只能等待，大大降低了并发操作的效率。
- Hashtable 或者同步包装版本，都只是适合在非高度并发的场景下。
ConcurrentHashMap 分析
- 早期 ConcurrentHashMap，其实现是基于：
  - 分离锁，也就是将内部进行分段（Segment），里面则是 HashEntry 的数组，和 HashMap 类似，哈希相同的条目也是以链表形式存放。
  - HashEntry 内部使用 volatile 的 value 字段来保证可见性，也利用了不可变对象的机制以改进利用 Unsafe 提供的底层能力，比如 volatile access，去直接完成部分操作，以最优化性能，毕竟 Unsafe 中的很多操作都是 JVM intrinsic 优化过的。
  - 核心是利用分段设计，在进行并发操作的时候，只需要锁定相应段，这样就有效避免了类似 Hashtable 整体同步的问题，大大提高了性能。
  - 在构造的时候，Segment 的数量由所谓的 concurrencyLevel 决定，默认是 16，也可以在相应构造函数直接指定。注意，Java 需要它是 2 的幂数值，如果输入是类似 15 这种非幂值，会被自动调整到 16 之类 2 的幂数值。
- 在 Java 8 和之后的版本中，ConcurrentHashMap 发生了哪些变化呢？
  - 总体结构上，它的内部存储变得和 HashMap 结构非常相似，同样是大的桶（bucket）数组，然后内部也是⼀个个链表结构（bin），同步的粒度要更细致⼀些。
  - 其内部仍然有 Segment 定义，但仅仅是为了保证序列化时的兼容性而已，不再有任何结构上的用处。
  - 因为不再使用 Segment，初始化操作大大简化，修改为 lazy-load 形式，这样可以有效避免初始开销。
  - 数据存储利⽤ volatile 来保证可见性。
  - 使用 CAS 等操作，在特定场景进行无锁并发操作。
  - 使用 Unsafe、LongAdder 之类底层手段，进行极端情况的优化。