ConcurrentHashMap是如何保证线程安全的?

发布网友 发布时间：2024-09-26 17:53

我来回答

共1个回答

热心网友 时间：2024-10-06 19:27

ConcurrentHashMap相当于是HashMap的多线程版本，它的功能本质上和HashMap没什么区别。因为HashMap在并发操作的时候会出现各种问题，比如死循环问题、数据覆盖等问题。而这些问题，只要使用ConcurrentHashMap就可以完美地解决。那问题来到了，ConcurrentHashMap它是如何保证线程安全的呢？

首先，我们来看JDK?1.7中ConcurrentHashMap的底层结构，它基本延续了HashMap的设计，采用的是数组?加?链表的形式。和HashMap不同的是，ConcurrentHashMap中的数组设计???分为大数组Segment和小数组HashEntry，来着这张图。

大树组Segment可以理解为一个数据库，而每个数据库（Segment）中又有很多张表（HashEntry），每个HashEntry中又有很多条数据，这些数据是用链表连接的。了解了ConcurrentHashMap的基本结构设计，我们再来看它的线程安全实现，就比较简单了。

接下来我们来对照JDK1.7中ConcurrentHashMap的put()方法源码实现。

因为Segment本身是基于ReentrantLock重入锁实现的加锁和释放锁的操作，这样就能保证多个线程同时访问ConcurrentHashMap时，同一时间只能有一个线程能够操作相应的节点，这样就保证了ConcurrentHashMap的线程安全。

也就是说ConcurrentHashMap的线程安全是建立在Segment加锁的基础上的，所以，我们称它为分段锁或者片段锁，如图中所示。

那JDK1.8又是如何实现的呢？

在JDK1.7中，ConcurrentHashMap虽然是线程安全的，但因为它的底层实现是数组加链表的形式，所以在数据比较多情况下，因为要遍历整个链表，会降低访问性能。所以，JDK1.8以后采用了数组?加??链表?加?红黑树的方式优化了ConcurrentHashMap的实现，具体实现如图所示。

当链表长度大于8，并且数组长度大于时，链表就会升级为红黑树的结构。JDK?1.8中的ConcurrentHashMap虽然保留了Segment的定义，但这，仅仅是为了保证序列化时的兼容性，不再有任何结构上的用处了。

那在JDK?1.8中ConcurrentHashMap的源码是如何实现的呢？它主要是使用了CAS?加?volatile?或者?synchronized?的方式来保证线程安全。

我们可以从源码片段中看到，添加元素时首先会判断容器是否为空，

如果为空则使用????volatile????加???CAS????来初始化，

如果容器不为空，则根据存储的元素计算该位置是否为空。

如果根据存储的元素计算结果为空则利用???CAS???设置该节点；

如果根据存储的元素计算为空不为空，则使用??synchronized???，然后，遍历桶中的数据，并替换或新增节点到桶中，

最后再判断是否需要转为红黑树。这样就能保证并发访问时的线程安全了。

如果把上面的执行用一句话归纳的话，就相当于是ConcurrentHashMap通过对头结点加锁来保证线程安全的。

这样设计的好处是，使得锁的粒度相比Segment来说更小了，发生hash冲突?和??加锁的频率也降低了，在并发场景下的操作性能也提高了。而且，当数据量比较大的时候，查询性能也得到了很大的提升。

最后，我们来总结一下：

1、ConcurrentHashMap在JDK?1.7中使用的数组?加?链表的结构，其中数组分为两类，大树组Segment?和?小数组?HashEntry，而加锁是通过给Segment添加ReentrantLock重入锁来保证线程安全的。

2、ConcurrentHashMap在JDK1.8中使用的是数组?加?链表?加?红黑树的方式实现，它是通过?CAS?或者?synchronized??来保证线程安全的，并且缩小了锁的粒度，查询性能也更高。

ConcurrentHashMap中有很多设计思想是值得我们去学习和借鉴的，比如说锁的粒度控制、分段锁的设计等等，都可以应用在实际的业务开发场景中。我们通过学习这些底层原理从中获取很多的设计思路，帮助我们更高效地去解决实际问题。

好了，关于ConcurrentHashMap的分享就讲到这里，听懂的小伙伴，请关注点个赞，下次不迷路。

本文为“Tom弹架构”原创，转载请注明出处。技术在于分享，我分享我快乐！\ 如果本文对您有帮助，欢迎关注和点赞；如果您有任何建议也可留言评论或私信，您的支持是我坚持创作的动力。关注微信公众号『 Tom弹架构 』可获取更多技术干货！

热心网友 时间：2024-10-06 19:25

ConcurrentHashMap相当于是HashMap的多线程版本，它的功能本质上和HashMap没什么区别。因为HashMap在并发操作的时候会出现各种问题，比如死循环问题、数据覆盖等问题。而这些问题，只要使用ConcurrentHashMap就可以完美地解决。那问题来到了，ConcurrentHashMap它是如何保证线程安全的呢？

首先，我们来看JDK?1.7中ConcurrentHashMap的底层结构，它基本延续了HashMap的设计，采用的是数组?加?链表的形式。和HashMap不同的是，ConcurrentHashMap中的数组设计???分为大数组Segment和小数组HashEntry，来着这张图。

大树组Segment可以理解为一个数据库，而每个数据库（Segment）中又有很多张表（HashEntry），每个HashEntry中又有很多条数据，这些数据是用链表连接的。了解了ConcurrentHashMap的基本结构设计，我们再来看它的线程安全实现，就比较简单了。

接下来我们来对照JDK1.7中ConcurrentHashMap的put()方法源码实现。

因为Segment本身是基于ReentrantLock重入锁实现的加锁和释放锁的操作，这样就能保证多个线程同时访问ConcurrentHashMap时，同一时间只能有一个线程能够操作相应的节点，这样就保证了ConcurrentHashMap的线程安全。

也就是说ConcurrentHashMap的线程安全是建立在Segment加锁的基础上的，所以，我们称它为分段锁或者片段锁，如图中所示。

那JDK1.8又是如何实现的呢？

在JDK1.7中，ConcurrentHashMap虽然是线程安全的，但因为它的底层实现是数组加链表的形式，所以在数据比较多情况下，因为要遍历整个链表，会降低访问性能。所以，JDK1.8以后采用了数组?加??链表?加?红黑树的方式优化了ConcurrentHashMap的实现，具体实现如图所示。

当链表长度大于8，并且数组长度大于时，链表就会升级为红黑树的结构。JDK?1.8中的ConcurrentHashMap虽然保留了Segment的定义，但这，仅仅是为了保证序列化时的兼容性，不再有任何结构上的用处了。

那在JDK?1.8中ConcurrentHashMap的源码是如何实现的呢？它主要是使用了CAS?加?volatile?或者?synchronized?的方式来保证线程安全。

我们可以从源码片段中看到，添加元素时首先会判断容器是否为空，

如果为空则使用????volatile????加???CAS????来初始化，

如果容器不为空，则根据存储的元素计算该位置是否为空。

如果根据存储的元素计算结果为空则利用???CAS???设置该节点；

如果根据存储的元素计算为空不为空，则使用??synchronized???，然后，遍历桶中的数据，并替换或新增节点到桶中，

最后再判断是否需要转为红黑树。这样就能保证并发访问时的线程安全了。

如果把上面的执行用一句话归纳的话，就相当于是ConcurrentHashMap通过对头结点加锁来保证线程安全的。

这样设计的好处是，使得锁的粒度相比Segment来说更小了，发生hash冲突?和??加锁的频率也降低了，在并发场景下的操作性能也提高了。而且，当数据量比较大的时候，查询性能也得到了很大的提升。

最后，我们来总结一下：

1、ConcurrentHashMap在JDK?1.7中使用的数组?加?链表的结构，其中数组分为两类，大树组Segment?和?小数组?HashEntry，而加锁是通过给Segment添加ReentrantLock重入锁来保证线程安全的。

2、ConcurrentHashMap在JDK1.8中使用的是数组?加?链表?加?红黑树的方式实现，它是通过?CAS?或者?synchronized??来保证线程安全的，并且缩小了锁的粒度，查询性能也更高。

ConcurrentHashMap中有很多设计思想是值得我们去学习和借鉴的，比如说锁的粒度控制、分段锁的设计等等，都可以应用在实际的业务开发场景中。我们通过学习这些底层原理从中获取很多的设计思路，帮助我们更高效地去解决实际问题。

好了，关于ConcurrentHashMap的分享就讲到这里，听懂的小伙伴，请关注点个赞，下次不迷路。

本文为“Tom弹架构”原创，转载请注明出处。技术在于分享，我分享我快乐！\ 如果本文对您有帮助，欢迎关注和点赞；如果您有任何建议也可留言评论或私信，您的支持是我坚持创作的动力。关注微信公众号『 Tom弹架构 』可获取更多技术干货！