JDK7与JDK8ConcurrentHashMap线程安全对比

本文深入对比了JDK 7与JDK 8中`ConcurrentHashMap`的线程安全实现，揭示了其设计哲学的演进。JDK 7采用分段锁机制，虽能提升并发度、降低锁竞争，但也存在Segment数量固定、`size()`操作开销大等局限。JDK 8则彻底抛弃分段锁，转而采用CAS+`synchronized`的混合策略，锁粒度更细，并引入红黑树优化，在高并发场景下性能更优。文章还探讨了分段锁的优缺点，以及JDK 8的关键改进，如移除Segment结构、CAS+`synchronized`混合策略、引入红黑树和优化扩容机制。最后，针对实际开发，文章给出了选择和使用`ConcurrentHashMap`的建议，强调理解其特性和适用场景的重要性，以便充分发挥其在高并发场景下的优势。

JDK 7采用分段锁提升并发性能，优点是减少锁竞争、提高读写并发度，缺点是Segment数量固定、size()开销大、扩容复杂；JDK 8改用CAS+synchronized细粒度锁，结合红黑树优化，提升高并发性能。

ConcurrentHashMap 在不同 JDK 版本中采用的线程安全机制有所演进：JDK 7 主要依赖“分段锁”（Segment Locking）来提高并发度，将整个 Map 划分为多个独立的段，每个段有自己的锁；而 JDK 8 则彻底摒弃了分段锁，转而采用“CAS（Compare-And-Swap）操作 + synchronized 锁”的混合策略，结合了更细粒度的锁和无锁操作，以期在更高的并发场景下表现更优。

解决方案

作为 Java 并发编程中不可或缺的组件，ConcurrentHashMap 的设计哲学一直围绕着如何在保证数据一致性的前提下，最大限度地提升并发性能。这背后不仅仅是技术的迭代，更是对并发模型理解的深化。

在 JDK 7 中，ConcurrentHashMap 引入了分段锁（Segment Locking）的概念。它将整个哈希表在逻辑上分成了多个小的哈希表，也就是 Segment。每个 Segment 都是一个独立的锁，继承自 ReentrantLock。当我们执行 put 或 remove 这类写入操作时，会根据键的哈希值计算它应该落在哪个 Segment 上，然后只锁定那个 Segment。这意味着，只要操作的键分布在不同的 Segment 上，它们就可以并发执行，而不会互相阻塞。读取操作，比如 get，在大多数情况下是不需要加锁的，它利用了 volatile 关键字的内存可见性保证，确保能读取到最新的数据，这大大提升了读操作的并发性。但这种设计也有其局限性，比如 Segment 的数量在初始化时就固定了，无法动态调整；当所有操作都集中在少数几个 Segment 上时，并发性能会下降；更重要的是，像 size() 这样的全局操作，需要遍历并锁定所有 Segment，这在并发场景下开销不小。我个人感觉，JDK 7 的设计在当时确实是开创性的，但它更像是一种“粗粒度”的优化，虽然解决了全局锁的痛点，但仍留下了进一步精进的空间。

到了 JDK 8，ConcurrentHashMap 的设计理念发生了根本性的转变，彻底移除了 Segment 结构。它回归到类似 HashMap 的“数组 + 链表/红黑树”结构，但巧妙地利用了 CAS 操作和 synchronized 关键字。现在，当我们要进行 put 操作时，如果对应的桶（bucket）是空的，或者只是在链表末尾添加新节点，它会尝试使用 CAS 操作来更新。CAS 是一种乐观锁机制，它假设没有冲突，直接尝试修改，如果发现数据已经被其他线程修改了（CAS 失败），则会重试或者退回到更保守的策略。当出现哈希冲突严重、需要修改链表内部结构（比如在中间插入、删除）或者进行扩容等复杂操作时，JDK 8 会使用 synchronized 关键字来锁定当前桶的头节点。注意，这里锁定的不再是整个 Segment，而是单个桶的头节点，这使得锁的粒度变得极细。同时，JDK 8 也引入了红黑树来优化长链表的查找性能，当链表长度超过一定阈值时，会转换为红黑树，提高查找效率。此外，扩容机制也变得更加精巧，它允许部分桶在扩容过程中被迁移，从而减少了对整个 Map 的阻塞时间。这种设计在我看来，无疑是更加优雅和高效的，它结合了无锁操作的高性能和悲观锁的安全性，实现了更优秀的并发控制。

JDK 7的ConcurrentHashMap为何采用分段锁，它有哪些优缺点？

JDK 7 时代的 ConcurrentHashMap 之所以选择分段锁，核心在于当时主流的并发控制策略。在那个时期，避免全局锁是提升并发性能的关键。设想一下，如果只有一个全局锁，那么所有的写操作都将串行执行，这在多核处理器上会造成严重的性能瓶颈。分段锁的思路，就是将一个大的问题拆分成多个小问题来解决，将一个 Map 拆分成多个 Segment，每个 Segment 独立加锁，从而允许多个线程同时对不同的 Segment 进行写操作。这就像在一个大型图书馆里，不是所有人都抢一个借书窗口，而是设置了多个独立的借书窗口，每个窗口服务一部分书籍。

其优点显而易见：

1. 提升并发度： 允许多个线程同时修改 Map 中不同 Segment 的数据，大大提高了写操作的并发性能。
2. 降低锁竞争： 相较于全局锁，锁的粒度更细，减少了线程间的竞争，尤其是在键值分布比较均匀的情况下。
3. 读操作优化： 大多数 get 操作无需加锁，通过 volatile 保证可见性，性能非常高。

然而，缺点也同样突出，并且在实践中逐渐暴露出来：

1. 初始化固定并发度： Segment 的数量在 ConcurrentHashMap 初始化时就确定了，无法动态调整。如果初始设置过小，并发度就受限；如果设置过大，又会造成内存浪费。
2. size() 操作开销大： 计算 Map 的总大小时，需要对所有 Segment 进行加锁并求和，这在并发环境下是一个耗时且可能阻塞其他操作的过程。
3. 哈希冲突影响： 如果大量哈希冲突导致数据集中在少数几个 Segment，那么这些 Segment 上的锁竞争依然会非常激烈，分段锁的优势便荡然无存。
4. 内存开销： 每个 Segment 都是一个 ReentrantLock 实例，会带来额外的内存消耗。
5. 扩容复杂性： 扩容操作需要重新哈希所有 Segment 中的元素，涉及所有 Segment 的协调，实现起来相对复杂。

总的来说，JDK 7 的分段锁是并发编程史上的一个重要里程碑，它为我们展示了如何通过细化锁粒度来提升并发性能。但随着硬件的发展和对更高并发需求的追求，其内在的局限性也促使了 JDK 8 版本的革新。

JDK 8对ConcurrentHashMap的线程安全机制做了哪些关键改进？

JDK 8 对 ConcurrentHashMap 的改进，我认为是一次从“宏观分治”到“微观精控”的转变，它不再依赖 Segment 这种粗粒度的分段，而是将并发控制下沉到更细致的节点层面。

最核心的改进在于：

1. 移除 Segment 结构： 这是最显著的变化。JDK 8 完全抛弃了 Segment 数组，ConcurrentHashMap 的底层结构直接是一个 Node 数组，类似于 HashMap 的 table 数组。这意味着不再有独立的 ReentrantLock 对象来代表一个“段”。
2. 采用 CAS + synchronized 的混合策略：
   • CAS 操作： 对于大多数非结构性修改（如在空桶中插入第一个节点，或在链表末尾追加节点），JDK 8 优先使用 CAS（Compare-And-Swap）操作。CAS 是一种无锁算法，它通过原子指令比较内存值是否与预期值相等，如果相等就更新为新值。这避免了加锁带来的上下文切换和性能损耗，大大提高了并发效率。
   • synchronized 关键字： 当 CAS 操作无法满足需求，或者涉及结构性修改（如链表中间插入/删除、扩容、链表转红黑树等）时，JDK 8 会使用 synchronized 关键字。但这里的 synchronized 锁定的不再是整个 Segment，而是当前桶的头节点（或 TreeBin 节点）。这意味着即使在有竞争的情况下，也只有操作同一个桶的线程会被阻塞，其他桶的操作仍然可以并发进行，锁的粒度达到了极致。
3. 引入红黑树： 为了解决哈希冲突严重时链表过长导致性能下降的问题，JDK 8 借鉴了 HashMap 的设计，当单个桶中的链表长度达到一定阈值（默认为 8）时，会自动转换为红黑树。这使得在最坏情况下（哈希冲突非常严重），查找、插入、删除操作的时间复杂度从 O(n) 降低到 O(log n)。
4. 优化扩容机制： JDK 8 的扩容机制也更加精细。它不再一次性锁定所有 Segment 进行扩容，而是采用了一种“分步扩容”的方式。通过 sizeCtl 字段和 ForwardingNode 节点，允许多个线程协助进行扩容，部分旧桶的数据可以并发迁移到新桶，从而减少了扩容期间对整个 Map 的阻塞时间，提高了可用性。
5. Unsafe 类的使用： 在底层，JDK 8 的 ConcurrentHashMap 大量使用了 sun.misc.Unsafe 类来进行直接内存操作，以实现 CAS 等原子操作，这提供了更高效的内存访问和原子性保证。

这些改进使得 JDK 8 的 ConcurrentHashMap 在高并发场景下表现出更优异的性能和扩展性，尤其是在多核处理器和大量并发写操作的环境中，其细粒度的并发控制策略能够更好地发挥硬件性能。

实际开发中，我们应该如何选择和使用ConcurrentHashMap？

在实际开发中，ConcurrentHashMap 无疑是处理高并发场景下共享 Map 数据结构的首选。但选择和使用它，并非只是简单地替换 HashMap 那么简单，我们需要对其特性和适用场景有深入的理解。

首先，优先选择 JDK 8 及更高版本的 ConcurrentHashMap。鉴于 JDK 8 在设计上的巨大优势，包括更细粒度的锁控制、红黑树优化以及更高效的扩容机制，它在绝大多数场景下都比 JDK 7 版本表现更好，性能和可伸缩性都得到了显著提升。除非你还在维护非常老的项目，否则没有理由继续使用 JDK 7 的实现。

何时使用 ConcurrentHashMap？

• 高并发读写场景： 当你的应用程序中，多个线程需要同时对一个共享的 Map 进行读写操作，并且对性能有较高要求时，ConcurrentHashMap 是理想的选择。例如，缓存系统、计数器、状态存储等。
• 替代 Collections.synchronizedMap()： Collections.synchronizedMap() 虽然也能保证线程安全，但它使用的是全局锁，并发性能远不如 ConcurrentHashMap。在需要高并发的场景下，应避免使用前者。

使用 ConcurrentHashMap 的注意事项和限制：

1. 弱一致性迭代器： ConcurrentHashMap 的迭代器（Iterator）是“弱一致性”（weakly consistent）的，这意味着它在遍历过程中，可能会反映出在迭代器创建后，其他线程对 Map 所做的修改。它不会抛出 ConcurrentModificationException，但也不能保证在迭代过程中看到 Map 的一个完全一致的快照。如果你需要一个严格一致的快照，你可能需要自行复制 Map 的内容到一个新的 Map 中，或者使用外部锁来保护迭代过程，但这会牺牲并发性。
2. 复合操作的原子性： ConcurrentHashMap 保证了单个操作（如 put, get, remove）的原子性。但是，如果你需要执行一系列操作，并且希望这些操作作为一个整体是原子性的（例如，“检查是否存在，如果不存在就插入，并基于插入结果做进一步处理”），那么 ConcurrentHashMap 本身无法保证这种复合操作的原子性。你需要自己使用外部同步机制（如 synchronized 块或 ReentrantLock）来保护这些复合操作，或者利用 ConcurrentHashMap 提供的原子操作方法，如 computeIfAbsent, putIfAbsent 等。
3. 避免在单线程环境中使用： 如果 Map 仅由一个线程访问，或者并发度极低，那么使用 ConcurrentHashMap 反而会带来不必要的开销（如 volatile 读写、CAS 操作等），此时 HashMap 会是更轻量、性能更好的选择。
4. 键值非空： ConcurrentHashMap 不允许 null 键或 null 值。这一点与 HashMap 不同，需要特别注意。

总而言之，ConcurrentHashMap 是 Java 并发工具箱中的一把利器，它在保证线程安全的同时，提供了出色的并发性能。但作为开发者，我们不能仅仅停留在“它能保证线程安全”的层面，更要深入理解其内部机制、适用场景和潜在限制，才能在实际项目中发挥它的最大价值，避免引入新的问题。

今天关于《JDK7与JDK8ConcurrentHashMap线程安全对比》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于concurrenthashmap,JDK7,JDK8,分段锁,CAS+synchronized的内容请关注golang学习网公众号！