HashMap与ConcurrentHashMap工作原理、区别和总结

最新推荐文章于 2024-08-17 15:37:16 发布

yjfcsdn

最新推荐文章于 2024-08-17 15:37:16 发布

阅读量2.1w

点赞数 30

分类专栏： Java知识点总结文章标签： Map集合

本文链接：https://blog.csdn.net/chenwendangding/article/details/99065623

版权

Java知识点总结专栏收录该内容

7 篇文章 2 订阅

订阅专栏

HashMap与ConcurrentHashMap工作原理和区别

区别：

HashMap不支持并发操作，没有同步方法，ConcurrentHashMap支持并发操作，通过继承 ReentrantLock（JDK1.7重入锁）/CAS和synchronized(JDK1.8内置锁)来进行加锁（分段锁），每次需要加锁的操作锁住的是一个 segment，这样只要保证每个 Segment 是线程安全的，也就实现了全局的线程安全。
JDK1.8之前HashMap的结构为数组+链表，JDK1.8之后HashMap的结构为数组+链表+红黑树；JDK1.8之前ConcurrentHashMap的结构为segment数组+数组+链表，JDK1.8之后ConcurrentHashMap的结构为数组+链表+红黑树。

1、JDK1.8之前和JDK1.8之后的HashMap工作原理：

JDK1.8之前：

HashMap结构

HashMap 里面是一个数组，然后数组中每个元素是一个单向链表,查找的时间复杂度为O(N),N为链表的长度;

数组和链表中的每个元素和节点都是嵌套类Entry的实例，Entry包括四个属性：key,value,hash,和用于单向链表的next;

Entry类实例定义为：

Static class Entry<K,V> implements Map.Entry<K,V>{

Final K key;

V value;

Entry<K,V>next;

int hash;

}

capacity：当前数组容量，始终保持 2^n，可以扩容，扩容后数组大小为当前的 2 倍。

loadFactor：负载因子，默认为 0.75。

threshold：扩容的阈值，等于 capacity * loadFactor

JDK1.8之后：

HashMap结构：数组+链表+红黑树，查找的时间复杂度降低为O(logN).

Java7 中使用Entry来代表每个HashMap中的数据节点，Java8中使用Node，基本没有区别，都是 key，value，hash 和 next 这四个属性，不过，Node 只能用于链表的情况，红黑树的情况需要使用 TreeNode。

我们根据数组元素中，第一个节点数据类型是 Node 还是 TreeNode 来判断该位置下是链表还是红黑树的。

另外，和 Java7 稍微有点不一样的地方就是，Java7 是先扩容后插入新值的，Java8 先插值再扩容，不过这个不重要。

Hashmap 的结构在JDK1.7和1.8有哪些区别（不同点）总结：

1、JDK1.7用的是头插法，而JDK1.8及之后使用的都是尾插法，那么他们为什么要这样做呢？因为JDK1.7是用单链表进行的纵向延伸，当采用头插法时会容易出现逆序且环形链表死循环问题。但是在JDK1.8之后是因为加入了红黑树使用尾插法，能够避免出现逆序且链表死循环的问题。

2、扩容后数据存储位置的计算方式也不一样：

1）在JDK1.7的时候是直接用hash值和需要扩容的二进制数进行&（这里就是为什么扩容的时候为啥一定必须是2的多少次幂的原因所在，因为如果只有2的n次幂的情况时最后一位二进制数才一定是1，这样能最大程度减少hash碰撞）（hash值 & length-1）

2）而在JDK1.8的时候直接用了JDK1.7的时候计算的规律，也就是扩容前的原始位置+扩容的大小值=JDK1.8的计算方式，而不再是JDK1.7的那种异或的方法。但是这种方式就相当于只需要判断Hash值的新增参与运算的位是0还是1就直接迅速计算出了扩容后的储存方式。

注：在计算hash值的时候，JDK1.7用了9次扰动处理=4次位运算+5次异或，而JDK1.8只用了2次扰动处理=1次位运算+1次异或。

JDK1.7的时候使用的是数组+ 单链表的数据结构。但是在JDK1.8及之后时，使用的是数组+链表+红黑树的数据结构（当链表的深度达到8的时候，也就是默认阈值，就会自动扩容把链表转成红黑树的数据结构来把时间复杂度从O（n）变成O（logN）提高了效率）

面试问题相关知识点

哈希表如何解决Hash冲突

2、为什么HashMap具备下述特点：键-值（key-value）都允许为空、线程不安全、不保证有序、存储位置随时间变化

3、为什么 HashMap 中 String、Integer 这样的包装类适合作为 key 键

4、HashMap 中的 key若是Object类型，则需实现哪些方法？

2、JDK1.8之前和JDK1.8之后的ConcurrentHashMap工作原理：

JDK1.8之前：

ConcurrentHashMap结构

ConcurrentHashMap结构分为两部分：segment数组，不可扩容；segment中的内部数组和链表，内部数组可扩容

concurrencyLevel：并行级别、并发数、Segment 数，默认值是16，也就是说 ConcurrentHashMap 有 16 个 Segments，所以理论上，这个时候，最多可以同时支持 16 个线程并发写，只要它们的操作分别分布在不同的 Segment 上。这个值可以在初始化的时候设置为其他值，但是一旦初始化以后，它是不可以扩容的。

JDK1.8之后：

ConcurrentHashMap结构

JDK1.8之后ConcurrentHashMap结构和JDK1.8之后的HashMap基本上一样，也是保持着数组+链表+红黑树的结构，不同的是，ConcurrentHashMap需要保证线程安全性。

ConcurrentHashMap总结和思考

可以看出JDK1.8版本的ConcurrentHashMap的数据结构已经接近JDK1.8版本的HashMap，相对而言，ConcurrentHashMap只是增加了同步的操作来控制并发，从JDK1.7版本的ReentrantLock+Segment+HashEntry，到JDK1.8版本中synchronized+CAS+HashEntry+红黑树,相对而言，总结如下思考：

JDK1.8的实现降低锁的粒度，JDK1.7版本锁的粒度是基于Segment的，包含多个HashEntry，而JDK1.8锁的粒度就是HashEntry（首节点）。
JDK1.8版本的数据结构变得更加简单，使得操作也更加清晰流畅，因为已经使用synchronized来进行同步，所以不需要分段锁的概念，也就不需要Segment这种数据结构了，由于粒度的降低，实现的复杂度也降低了。
JDK1.8使用红黑树来优化链表，基于长度很长的链表的遍历是一个很漫长的过程，而红黑树的遍历效率是很快的，代替一定阈值的链表，这样形成一个最佳拍档。
JDK1.8为什么使用内置锁synchronized来代替重入锁ReentrantLock，有以下几点：

因为粒度降低了，在相对而言的低粒度加锁方式，synchronized并不比ReentrantLock差，在粗粒度加锁中ReentrantLock可能通过Condition来控制各个低粒度的边界，更加的灵活，而在低粒度中，Condition的优势就没有了。
JVM的开发团队从来都没有放弃synchronized，而且基于JVM的synchronized优化空间更大，使用内嵌的关键字比使用API更加自然。
在大量的数据操作下，对于JVM的内存压力，基于API的ReentrantLock会开销更多的内存，虽然不是瓶颈，但是也是一个选择依据。