四种线程安全的hashMap

hash表

1.介绍

哈希表就是一种以 键-值(key-indexed) 存储数据的结构，我们只要输入待查找的值即key，即可查找到其对应的值。

哈希的思路很简单，如果所有的键都是整数，那么就可以使用一个简单的无序数组来实现：将键作为索引，值即为其对应的值，这样就可以快速访问任意键的值。这是对于简单的键的情况，我们将其扩展到可以处理更加复杂的类型的键。

2.链式哈希表

链式哈希表从根本上说是由一组链表构成。每个链表都可以看做是一个“桶”，我们将所有的元素通过散列的方式放到具体的不同的桶中。插入元素时，首先将其键传入一个哈希函数（该过程称为哈希键），函数通过散列的方式告知元素属于哪个“桶”，然后在相应的链表头插入元素。查找或删除元素时，用同们的方式先找到元素的“桶”，然后遍历相应的链表，直到发现我们想要的元素。因为每个“桶”都是一个链表，所以链式哈希表并不限制包含元素的个数。然而，如果表变得太大，它的性能将会降低。

3.应用场景

我们熟知的缓存技术（比如redis、memcached）的核心其实就是在内存中维护一张巨大的哈希表。

一、ConcurrentHashMap

ConcurrentHashMap与HashMap的区别

HashMap是线程不安全的，在多线程环境下，使用Hashmap进行put操作会引起死循环，导致CPU利用率接近100%，所以在并发情况下不能使用HashMap。

主要就是为了应对hashmap在并发环境下不安全而诞生的，ConcurrentHashMap的设计与实现非常精巧，大量的利用了volatile，final，CAS等lock-free技术来减少锁竞争对于性能的影响。

HashMap一般都是数组+链表结构（JDK1.7）

HashMap一般都是数组+链表结构  一（桶位hash值重复数量大于8）一>  数组+红黑树

CurrentHashMap的实现原理

JDK1.7 ConcurrentHashMap采用了数组+Segment+分段锁的方式实现

1.Segment(分段锁)

ConcurrentHashMap中的分段锁称为Segment，它即类似于HashMap的结构，即内部拥有一个Entry数组，数组中的每个元素又是一个链表,同时又是一个ReentrantLock（Segment继承了ReentrantLock--公平锁机制）。

2.内部结构

ConcurrentHashMap使用分段锁技术，将数据分成一段一段的存储，然后给每一段数据配一把锁，当一个线程占用锁访问其中一个段数据的时候，其他段的数据也能被其他线程访问，能够实现真正的并发访问。如下图是ConcurrentHashMap的内部结构图：

ConcurrentHashMap定位一个元素的过程需要进行两次Hash操作。第一次Hash定位到Segment，第二次Hash定位到元素所在的链表的头部。

3.该结构的优劣势

Hash的过程要比普通的HashMap要长

写操作的时候可以只对元素所在的Segment进行加锁即可，不会影响到其他的Segment，这样，在最理想的情况下，ConcurrentHashMap可以最高同时支持Segment数量大小的写操作（刚好这些写操作都非常平均地分布在所有的Segment上）。ConcurrentHashMap的并发能力可以大大的提高

JDK1.8 ConcurrentHashMap采用了数组+链表+红黑树的实现方式来设计，内部大量采用CAS操作

1.CAS

compare and swap的缩写，即我们所说的比较交换。cas是一种基于锁的操作，而且是乐观锁。在java中锁分为乐观锁和悲观锁。悲观锁是将资源锁住，等一个之前获得锁的线程释放锁之后，下一个线程才可以访问。而乐观锁采取了一种宽泛的态度，通过某种方式不加锁来处理资源，比如通过给记录加version来获取数据，性能较悲观锁有很大的提高。

CAS 操作包含三个操作数 —— 内存位置（V）、预期原值（A）和新值(B)。如果内存地址里面的值和A的值是一样的，那么就将内存里面的值更新成B。CAS是通过无限循环来获取数据的，若果在第一轮循环中，a线程获取地址里面的值被b线程修改了，那么a线程需要自旋，到下次循环才有可能机会执行。

JDK8中彻底放弃了Segment转而采用的是Node，其设计思想也不再是JDK1.7中的分段锁思想。

在JDK8中ConcurrentHashMap的结构，由于引入了红黑树，使得ConcurrentHashMap的实现非常复杂，我们都知道，红黑树是一种性能非常好的二叉查找树，其查找性能为O（logN），但是其实现过程也非常复杂，而且可读性也非常差，DougLea的思维能力确实不是一般人能比的，早期完全采用链表结构时Map的查找时间复杂度为O（N），JDK8中ConcurrentHashMap在链表的长度大于某个阈值的时候会将链表转换成红黑树进一步提高其查找性能。

总结

1.数据结构：取消了Segment分段锁的数据结构，取而代之的是数组+链表+红黑树的结构。

2.保证线程安全机制：JDK1.7采用segment的分段锁机制实现线程安全，其中segment继承自ReentrantLock。JDK1.8采用CAS+Synchronized保证线程安全。

3.锁的粒度：原来是对需要进行数据操作的Segment加锁，现调整为对每个数组元素加锁（Node）。

4.链表转化为红黑树:定位结点的hash算法简化会带来弊端,Hash冲突加剧,因此在链表节点数量大于8时，会将链表转化为红黑树进行存储。

5.查询时间复杂度：从原来的遍历链表O(n)，变成遍历红黑树O(logN)。

二、Hashtable

增、删操作采用synchronized方法上加锁，使用阻塞同步，效率低

三、Collections.synchronizedMap

更不可取，也是采用synchronized方法上加锁，使用阻塞同步，效率低。

四、CopyOnWriteMap（读写分离思想）

（java本身并没有提供CopyOnWriteMap，但是我们可以自己实现一个，代码见下）

采用 写时复制 的操作

写时复制：

当对容器进行增加，删除，修改操作时，不是直接操作容器，而是先将当前容器copy，复制出一个新的容器，再对新容器进行操作，操作完成后再将指针指向这个新容器。这样做的好处是我们可以对CopyOnWrite容器进行并发的读（CopyOnWriteArrayList底层使用数组实现，而该数组是被volatile修饰），而不用对其进行加锁，当然写的时候是需要加锁的（这里采用了lock加锁），否则可能copy出了N个副本。

优点：写时不用加锁，即查询不加锁，在查询多，增删改少的情况下适合用。

缺点（问题）：内存占用和数据一致性

1.内存占用

因为CopyOnWrite的写时复制机制，所有在进行写操作的时候，内存里会同时驻扎两个对象的内存，旧的对象和新的对象。如果这些对象占用的内存比较大，就有可能造成频繁的yong GC和full GC。

解决：

可以通过压缩容器中的元素的方法来减少大对象的消耗，如元素全是10进制的数字，可以考虑将其压缩成32进制或者64进制.

使用其他的并发容器，如ConcurrentHashMap。

2.数据一致性

CopyOnWrite容器只能保证数据的最终一致性，不能保证数据的实时一致性（因为在对新容器进行写操作时，其它线程可能也在操作原容器）。所有如果你希望写入的数据，马上能读到，CopyOnWrite可能无法满足要求。

CopyOnWriteMap的实现代码: