多线程（4）——ConcurrentHashMap（含部分源码说明）

1.ConcurrentHashMap的引入

1.HashMap的引入：
要是不太懂HashMap ,请先阅读这个关于HashMap的思维导图：https://editor.csdn.net/md/?articleId=119273788

大体来说：
（1）结合了数组的快速访问下标的操作和链表的快速插入产出特性而设计出的一种数据结构。
（2）1.7中是数组 + 链表 ， 1.8中是数组 + 链表 + 红黑树
（3）1.7到1.8的变化，防止了Hash冲突严重，导致链表长度太大，查询效率低的原因。改变了链表插入位置，保证死循环问题。

2.HashTable的引入：

大体来说：
上边说了，HashMap是线程不安全的，所以有没有安全的Map结构呢？下边就引入了HashTable 。它和HashMap 的结构相同，唯一不同的是，它在方法上加上了synchronized短见字来修饰，保证了线程安全。

要是不是很理解HashTable,请先学习这篇文章，里边有详细的接收HashTable：https://editor.csdn.net/md/?articleId=119279769

3.ConcurrentHashMap的引入：

既然上边的HashTable能够保证线程安全了，那么为何还要进入ConcurrentHashMap？

最大的原因就是，HashTable 确实能保证线程安全，但是它是直接用synchronized修饰的，是系统级别的Mutex 锁。不论是加锁还是释放锁都会有很大的开销。因此它的性能还不是很好。

为了提高HashTable 的性能，引入concurrentHashMap

2.内部数据结构

（1）在jdk 1.7中

（1）ConcurrentHashMap内部数据结构是：数组 + 链表
（2）这里的数组叫做分段数组（segment数组）
（3）分段数组里边存的是一个链表（hash冲突时会给链表里边插入），链表里边存的内容是键值对（HashEntry）。

（2）在 jdk 1.8中

（1）内部数据结构是： 数组 + 链表 + 红黑树,和HashMap一样。
（2）为啥要引入红黑树： 和HashMap一样，要是哈希冲突严重，就会导致插入的键值对一直是给链表后边插入，这样链表的长度就会太长，在进行get查询操作时，效率会很低。

3. 起到的作用

首先ConcurrentHashMap是满足高并发的Map 结构。能在保证安全的前提下，能提高并发性，提升性能。

（1）高并发体现之一：

不论是 jdk1.7 还是 jdk 1.8 ，ConcurrentHashMap的源码中用final 修饰key ,用volatile修饰 value 和 HashEntry，保证了线程安全性。保证读读并发，读写并发，写写互斥。 这样多个线程之间读读 、 读写就能并发进行 ，提高效率。

源码

（2）高并发体现之二：
不管是 jdk 1.7 还是 jdk 1.8 都是通过加锁的粒度来提高并发的。

1. 对于jdk 1.7来说：

（1） 它直接给分段锁进行加锁，分段锁（segment）继承于ReentrantLock，当一个线程占用segment锁访问一个segment时，其他的segment不会受到影响。支持并发进行。就是将 原来的给整个数组加锁，改变为给其中的一段进行加锁。锁的粒度更细了，并发程度更高。
（2）存在的问题，上边说的，是给分段锁加锁，就是给数组中的一个下标进行加锁，因为数组中的每一个元素存的又是一个链表。就是给一个链表中的每一个hashEntry加锁。要是发生哈希冲突严重的话，还是存在遍历链表查询。效率会很低。

2.对于 jdk 1.8 来说：

（1）在 1.7 的基础上，加锁的粒度更细。将原来的给数组中的一个段落加锁，变成了给段落中的具体的节点加锁，并发程度更高。
（2）采用的是CAS + synchronized保证线程安全。
（3）在进行put 操作时：要是计算出的hash值是null，就基于CAS进行加锁并插入。要是计算出的hash值不是null，就使用synchronized 锁住该元素，再进行往里边插入。

（3）下边是 jdk 1.8中的源码，用的是CAS + synchronized的方式保证线程安全。