本文探讨了为何ConcurrentHashMap在1.8版本的读操作不需要加锁。通过分析get操作源码，指出其利用volatile关键字确保可见性和有序性，而Node的val和next字段的volatile修饰在多线程环境下提供了无锁读取的安全性。数组的volatile修饰主要是为了解决扩容时的可见性问题。
目录
- ConcurrentHashMap的简介
- get操作源码
- volatile登场
- 是加在数组上的volatile吗?
- 用volatile修饰的Node
- 总结
我们知道，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使用红黑树来优化链表，基于长度很长的链表的遍历是一个很漫长的过程，而红黑树的遍历效率是很快的，代替一定阈值的链表，这样形成一个最佳拍档
最低0.47元/天 解锁文章
476
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
