jdk7、jdk8 hashmap、concurrenthashmap以及他们的区别

打个小guang告,搜索拼duoduo店铺: Boush杂货铺
物美价廉,你值得拥有

jdk7、jdk8 hashmap、concurrenthashmap以及他们的区别

一、hashmap1.7

1.数据结构

也称为哈希数组,默认数组大小是16,每对key-value键值对其实是存在map的内部类entry里的,如果不同的key映射到了数组的同一位置处,就会采用头插法将其放入单链表中。

2.hashmap原理(put、get)

2.1.put原理

1.根据key获取对应hash值:int hash = hash(key.hashcode())

2.根据hash值和数组长度确定对应数组位置 int i = indexFor(hash, table.length); 简单理解就是i = hash值%模以 数组长度(其实是按位与运算)。如果不同的key都映射到了数组的同一位置处,就将其放入单链表中。且新来的是放在头节点,即投头插法。

2.2.get原理

1.通过hash获得对应数组位置,遍历该数组所在链表(key.equals())

3.hashcode冲突怎么办?为什么这么处理

1.采用头插法,直接放在链表的头部

2.因为HashMap的作者认为,后插入的Entry被查找的概率大些,所以放在头部(因为get())查询的时候会遍历整个链表)

4.hashmap的默认数组长度是多少?为什么?

16,是为了服务于从key映射到index的hash算法(看下面)。

5.hashmap达到默认负载因子(0.75)怎么办?为啥要16或者2的幂次?

1.自动双倍扩容,扩容后重新计算每个键值对位置。且长度必须为16或者2的幂次

2.若不是16或者2的幂次,位运算的结果不够均匀分布,显然不符合Hash算法均匀分布的原则。反观长度16或者其他2的幂,Length-1的值是所有二进制位全为1,这种情况下,index的结果等同于HashCode后几位的值。只要输入的HashCode本身分布均匀,Hash算法的结果就是均匀的。

6.hashmap是线程安全的么?为什么?

不是线程安全的,因为没有枷锁

7.并发会导致什么问题?

hashmap在接近临界点时,若此时两个或者多个线程进行put操作,都会进行resize(扩容)和ReHash(为key重新计算所在位置),而ReHash在并发的情况下可能会形成链表环。在执行get的时候,会触发死循环,引起CPU的100%问题。

注:jdk8已经修复hashmap这个问题了,jdk8中扩容时保持了原来链表中的顺序,即put不再采用头插法,而是尾插法。但是HashMap仍是非并发安全,在并发下,还是要使用ConcurrentHashMap。

8.hashmap和hashtable的区别

两者的区别
两者的区别
不安全更高16key-value都允许hashtable安全略低11不允许(抛异常)

\ 线程 效率 null值 数组默认值 扩容 继承自
hashmap 不安全 更高 key-value都允许null 16 16*0.75 = 12,当前个数大于等于阈值,则扩容为原来的2倍 AbstractMap
hashtable 安全 略低 不允许(抛异常) 11 11*0.75=12,扩容为原来的2倍+1 Dictionary

9.为啥hashtable不允许key、value为null

1.这是因为Hashtable使用的是安全失败机制(fail-safe),这种机制会使你此次读到的数据不一定是最新的数据。

如果你使用null值,就会使得其无法判断对应的key是不存在还是为空,因为你无法再调用一次contain(key)来对key是否存在进行判断,调用contain方法时hashtable有可能已经被更新过了。

10.安全失败(fail-safe)、快速失败(fail-fase)

hashtable使用的迭代器是Enumerator,是安全失败(fail-safe)机制
hashmap使用的是Iterator迭代器,是快速失败(fail-fast)机制,当其他线程改变了HashMap 的结构,如:增加、删除元素,将会抛出ConcurrentModificationException 异常,而 Hashtable则不会。

二、hashmap1.8

1.jdk1.8做了哪些优化?

1.为了加快查询效率,java8的hashmap引入了红黑树结构,当数组长度大于默认阈值64时,且当某一链表的元素>8时,该链表就会转成红黑树结构,查询效率更高。(问题来了,什么是红黑树?什么是B+树?(mysql索引有B+树索引)什么是B树?什么是二叉查找树?)数据结构方面的知识点这里不展开。

这里只简单的介绍一下红黑树:

红黑树是一种自平衡二叉树,拥有优秀的查询和插入/删除性能,广泛应用于关联数组。对比AVL树,AVL要求每个结点的左右子树的高度之差的绝对值(平衡因子)最多为1,而红黑树通过适当的放低该条件(红黑树限制从根到叶子的最长的可能路径不多于最短的可能路径的两倍长,结果是这个树大致上是平衡的),以此来减少插入/删除时的平衡调整耗时,从而获取更好的性能,而这虽然会导致红黑树的查询会比AVL稍慢,但相比插入/删除时获取的时间,这个付出在大多数情况下显然是值得的。

2.优化扩容方法,在扩容时保持了原来链表中的顺序,避免出现死循环,插入采用尾插法,而不是头插法

三、concurrenthashmap1.7

1.数据结构

Segment + entry
理解:hashmap是有entry数组组成,而concurrenthashmap则是Segment数组组成。而Segment又是什么呢?Segment本身就相当于一个HashMap。同HashMap一样,Segment包含一个HashEntry数组,数组中的每一个HashEntry既是一个键值对,也是一个链表的头节点。

像这样的Segment对象,在ConcurrentHashMap集合中有多少个呢?有2的N次方个,共同保存在一个名为segments的数组当中。
可以说,ConcurrentHashMap是一个二级哈希表。在一个总的哈希表下面,有若干个子哈希表。(这样类比理解多个hashmap组成一个cmap)

2.put、get方法

1.Put方法:

1.为输入的Key做Hash运算,得到hash值。
2.通过hash值,定位到对应的Segment对象
3.获取可重入锁
4.再次通过hash值,定位到Segment当中数组的具体位置。
5.插入或覆盖HashEntry对象。
6.释放锁。

2.Get方法:

1.为输入的Key做Hash运算,得到hash值。
2.通过hash值,定位到对应的Segment对象
3.再次通过hash值,定位到Segment当中数组的具体位置。
由此可见,和hashmap相比,ConcurrentHashMap在读写的时候都需要进行二次定位。先定位到Segment,再定位到Segment内的具体数组下标。

四、concurrenthashmap1.8

1.8的实现已经抛弃了Segment分段锁机制,利用Node数组+CAS+Synchronized来保证并发更新的安全,底层采用数组+链表+红黑树的存储结构。

针对 synchronized 获取锁的方式,jdk1.8中JVM使用了锁升级的优化方式,效率比之前高很多,就是先使用偏向锁优先同一线程再次获取锁,如果失败,就升级为CAS轻量级锁,如果失败就会短暂自旋,防止线程被系统挂起。最后如果以上都失败就升级为重量级锁。

引用地址:
https://mp.weixin.qq.com/s/UM21yeO242d-EVy8EL5Xww
https://mp.weixin.qq.com/s/AixdbEiXf3KfE724kg2YIw

猜你喜欢

转载自blog.csdn.net/godloveleo9527/article/details/105030118