Java 中 ConcurrentHashMap 1.7 和 1.8 之间有哪些区别?
在初次接触 ConcurrentHashMap 时，许多同学难免会对它高并发环境下的设计原理心生好奇。要弄清它在不同版本之间究竟有何差异，就需要先探究底层原理的“前世今生”。本文将聚焦 Java 1.7 和 Java 1.8 中 ConcurrentHashMap 的实现差异，带领大家从技术演变的角度一探究竟。
为什么会关心 1.7 和 1.8 的差异？
很多人第一次学习 ConcurrentHashMap 时，看到网上的教程、源码分析可能会发现有些地方解释不一致，或者明明听说它用到了“Segment 分段锁”，却又在源码中发现“Node、红黑树”的身影。其实，这主要是因为 Java 1.7 和 1.8 版本的实现思路发生了比较大的转变，导致同一个类在两个版本里呈现出完全不一样的结构。
如果你在项目中必须兼容老版本 JDK，或者使用了新版本 JDK 却发现文档、博客说法互相矛盾，那么你一定会迫切想要弄清这背后的原因。要消除这种“信息焦虑”，我们就得看看 1.7 时代和 1.8 时代的 ConcurrentHashMap 究竟有哪些核心差异。
Java 1.7 中的 ConcurrentHashMap
1. 核心设计——Segment 分段锁
在 Java 1.7 中，ConcurrentHashMap 的核心结构可以理解为一组“Segment 分段”，每个 Segment 都是一个小型的哈希表，并通过 ReentrantLock 来进行并发控制。可以把每个 Segment 看作是一个独立的锁定区域，这样在进行并发访问时，如果两个线程操作的 key 位于不同的 Segment，那么它们就可以并行操作而互不干扰。
- Segment[] segments：存放若干 Segment 的数组，Segment 数组长度通常是 2 的幂次方，用于快速定位具体的分段。
- 单个 Segment：每个 Segment 内部维持着一个散列表结构（类似 HashEntry[] table），采用 ReentrantLock 来保证对这一区域的数据安全。
优点：
- 分段锁的设计使得并发粒度相对粗中带细，相较于对整个哈希表加一把全局锁而言，并发性能已经提升不少。
- 同时保留了散列表常见的“数组 + 链表”结构，思想相对容易理解。
缺点：
- 如果哈希分布不均衡，某些 Segment 会成为热点，引发竞争，甚至演变成单点瓶颈。
- Segment 数组的容量、扩容也会带来一定复杂度，每次扩容都要把数据从旧的 Segment 搬移到新的 Segment 中。
- 对于“链表过长”的问题，1.7 版本没有采用进一步的优化（如红黑树），当 hash 冲突严重时，查询效率会降低。
Java 1.8 中的 ConcurrentHashMap
1. 结构变动——放弃 Segment
到了 Java 1.8，官方对 ConcurrentHashMap 进行了重构，核心设计从“Segment 分段锁”转向了“Node + CAS + Synchronized” 的组合。可以简单理解为**“去掉了 Segment，直接用一个 Node 数组，并辅以线程安全的操作”** 。
- Node[] table：不再有 Segment 数组，顶层仅保留一个 Node 数组。
- 红黑树：当某个桶（bucket）中链表过长，超过阈值时，会转换为红黑树结构，在极端情况下保持查询效率为 O(log n) ，大幅提升性能。
- CAS + Synchronized：1.8 中使用 CAS（Compare And Set）来保证在初始化、扩容、插入等关键操作中的原子性，同时对于链表或红黑树的操作会使用极小粒度的同步，以减少锁开销。
优点：
- 结构更简洁，无需再维护一组 Segment 的琐碎管理，降低了代码复杂度。
- 当出现 hash 冲突时，可以退化成链表或转化为红黑树，极大地提高了高并发情况下的查询与插入效率。
- 扩容时采用了分段转移（transfer）策略，加之 CAS 机制，极大减少了锁冲突的可能性。
缺点：
- 代码逻辑更为复杂，尤其在扩容、树化过程中的并发细节，阅读和理解成本更高。
- 对红黑树这种数据结构不熟悉的同学，可能需要额外学习这部分内容。
如何深入理解底层原理？
很多人关心这个问题的深层心理，其实是想确认：我的并发场景下，该怎么正确而高效地使用 ConcurrentHashMap？
- 如果你正在项目中遇到锁争用情况、对性能敏感，可能就会更关注 1.8 中这些使用 CAS 及红黑树的优化。
- 如果你还在用 Java 1.7 或者打算迁移到 Java 1.8，就需要知道哪些写法在老版本不兼容，或者在新版本中有更好的表现。
要真正吃透这些差异，建议亲自阅读部分源码并进行简单的压测。一些关键的源码方法，比如 putVal()、transfer() 等，对掌握并发思路非常有帮助。
小结
- Java 1.7 的 ConcurrentHashMap：使用 Segment 分段锁 进行并发控制。结构上由多个 Segment 组成，每个 Segment 内部是一个小哈希表并配合 ReentrantLock 来实现同步。优点在于思想易理解，但在极端 hash 冲突或扩容时的性能会受到影响。
- Java 1.8 的 ConcurrentHashMap：结构大调整，去掉 Segment，采用 Node 数组 + CAS + Synchronized 进行更细粒度的并发控制，同时引入 红黑树 优化冲突，在高并发场景和极端冲突情况下性能更优秀。
在实际开发中，如果你使用的是 Java 1.8 及以上版本，大部分情况下只需熟知其 CAS + 红黑树的思路，就能轻松应对大多数高并发挑战；如果仍停留在 Java 1.7，除了了解 Segment 机制，也要考虑尽快升级以享受更完善的并发性能和数据结构优化。
希望这篇文章能帮助你看清 ConcurrentHashMap 的迭代思路，也祝你在各自的项目里能选用最合适的并发解决方案，一路畅通无阻！