本文探讨了为何ConcurrentHashMap在JDK1.8中的get操作不需要加锁。1.8版通过Node+CAS+Synchronized实现并发安全，降低了锁的粒度。volatile关键字确保了数据的可见性和有序性，避免指令重排序。数组的volatile确保在扩容时对其他线程的可见性。因此，get操作能无锁执行，提高了并发集合的安全性和效率。
我们知道，ConcurrentHashmap(1.8)这个并发集合框架是线程安全的，当你看到源码的get操作时，会发现get操作全程是没有加任何锁的，这也是这篇博文讨论的问题——为什么它不需要加锁呢？
ConcurrentHashMap的简介
我想有基础的同学知道在jdk1.7中是采用Segment + HashEntry + ReentrantLock的方式进行实现的，而1.8中放弃了Segment臃肿的设计，取而代之的是采用Node + CAS + Synchronized来保证并发安全进行实现。
- JDK1.8的实现降低锁的粒度，JDK1.7版本锁的粒度是基于Segment的，包含多个HashEntry，而JDK1.8锁的粒度就是HashEntry（首节点）
- JDK1.8版本的数据结构变得更加简单，使得操作也更加清晰流畅，因为已经使用synchronized来进行同步，所以不需要分段锁的概念，也就不需要Segment这种数据结构了，由于粒度的降低，实现的复杂度也增加了
- JDK1.8使用红黑树来优化链表，基于长度很长的链表的遍历是一个很漫长的过程，而红黑树的遍历效率是很快的，代替一定阈值的链表，这样形成一个最佳拍档
get操作源码
- 首先计算hash值，定位到该t
最低0.47元/天 解锁文章
570
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
