JDK7和JDK8concurrentHashmap区别

哈希表

1.介绍

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

哈希的思路很简单，若是全部的键都是整数，那么就可使用一个简单的无序数组来实现：将键做为索引，值即为其对应的值，这样就能够快速访问任意键的值。这是对于简单的键的状况，咱们将其扩展到能够处理更加复杂的类型的键。

2.链式哈希表

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

3.应用场景

咱们熟知的缓存技术（好比redis、memcached）的核心其实就是在内存中维护一张巨大的哈希表，还有你们熟知的HashMap、CurrentHashMap等的应用。

ConcurrentHashMap与HashMap等的区别

1.HashMap

咱们知道HashMap底层是数组+链表实现的，是线程不安全的，在多线程环境下，使用Hashmap进行put操做会引发死循环，致使CPU利用率接近100%，因此在并发状况下不能使用HashMap。

2.HashTable

HashTable和HashMap的实现原理几乎同样，差异无非是

•  HashTable不容许key和value为null，而HashMap均可以，基于陈旧的 Dictionary 类。
•  HashTable是线程安全的

可是HashTable线程安全的策略实现代价却太大了，简单粗暴，get/put全部相关操做都是synchronized的，这至关于给整个哈希表加了一把大锁。

多线程访问时候，只要有一个线程访问或操做该对象，那其余线程只能阻塞，至关于将全部的操做串行化，在竞争激烈的并发场景中性能就会很是差。

3.ConcurrentHashMap

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

咱们都知道Map通常都是数组+链表结构（JDK1.8该为数组+红黑树）。

 

ConcurrentHashMap避免了对全局加锁改为了局部加锁操做，这样就极大地提升了并发环境下的操做速度，因为ConcurrentHashMap在JDK1.7和1.8中的实现很是不一样，接下来咱们谈谈JDK在1.7和1.8中的区别。

JDK1.7版本的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版本的CurrentHashMap的实现原理

JDK8中ConcurrentHashMap参考了JDK8 HashMap的实现，采用了数组+链表+红黑树的实现方式来设计，内部大量采用CAS操做。

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

Node：保存key，value及key的hash值的数据结构。其中value和next都用volatile修饰，保证并发的可见性。

Java8 ConcurrentHashMap结构基本上和Java8的HashMap同样，不过保证线程安全性。

 

在JDK8中ConcurrentHashMap的结构，因为引入了红黑树，使得ConcurrentHashMap的实现很是复杂，咱们都知道，红黑树是一种性能很是好的二叉查找树，其查找性能为O（logN），可是其实现过程也很是复杂，并且可读性也很是差，Doug
Lea的思惟能力确实不是通常人能比的，早期彻底采用链表结构时Map的查找时间复杂度为O（N），JDK8中ConcurrentHashMap在链表的长度大于某个阈值的时候会将链表转换成红黑树进一步提升其查找性能。

总结

其实能够看出JDK1.8版本的ConcurrentHashMap的数据结构已经接近HashMap，相对而言，ConcurrentHashMap只是增长了同步的操做来控制并发，从JDK1.7版本的ReentrantLock+Segment+HashEntry，到JDK1.8版本中synchronized+CAS+HashEntry+红黑树。

1.数据结构：取消了Segment分段锁的数据结构，取而代之的是数组+链表+红黑树的结构。
2.保证线程安全机制：JDK1.7采用segment的分段锁机制实现线程安全，其中segment继承自ReentrantLock。JDK1.8采用CAS+Synchronized保证线程安全。3.锁的粒度：原来是对须要进行数据操做的Segment加锁，现调整为对每一个数组元素加锁（Node）。4.链表转化为红黑树:定位结点的hash算法简化会带来弊端,Hash冲突加重,所以在链表节点数量大于8时，会将链表转化为红黑树进行存储。5.查询时间复杂度：从原来的遍历链表O(n)，变成遍历红黑树O(logN)。