HashMap
HashMap底层数据结构
JDK7:数组+链表
JDK8:数组+链表+红黑树(JDK8中使用了单项链表,也使用了双向链表,双向链表主要是为了链表操作方便,插入扩容链表转红黑树,红黑树转链表的过程中都要操作链表)
JDK8中HashMap为什么要使用红黑树
当元素个数小于一个阈值时,链表整体的插入和查询效率要高于红黑树,但元素个数大于此阈值时,链表整体的插入查询效率要低于红黑树。此阈值在HashMap中为8。
JDK8中HashMap什么时候将链表转换为红黑树
这个问题很容易打错,大部分答案是:单链表中元素大于8时就会把链表转化为红黑树。但其实还有另外一个限制:当发现链表中的元素个数大于8之后,还会判断一下当前数组的长度,如果长度小于64是,此时并不会转化为红黑树,而是进行扩容。只有链表中的元素大于8,并且数组的长度大于等于64时才会将链表转化为红黑树。
上面扩容的原因是,如果数组长度还比较小,就先利用扩容来缩小链表的长度。
JDK8中HashMap的put方法实现过程
- 根据key生成hashcode
- 判断当前HashMap对象的中的数组是否为空,如果为空则初始化该数组
- 根据逻辑与运算,算出hashcode基于当前数组对应的数组下标i
- 判断数组的第i个位置的元素(tab[i])是否为空
a. 如果为空,则将key和value封装为Node对象赋值给tab[i]
b. 如果不为空:
i. 如果put方法传进来的key等于tab[i].key,那么证明存在相同的key
ii. 如果不等于tab[i].key,则:
1. 如果tab[i]的类型是TreeNode,则表示数组的第i个位置上是一颗红黑树,那么将key好value插入到红黑树中,并在插入前会判断红黑树中是否存在相同的key
2. 如果tab[i]的类型不是TreeNode,则表示数组的第i个位置上是一个链表,那么遍历链表是否存在相同的key,并在遍历的过程中对链表中的节点数进行计数,当遍历到最后一个节点时,会将key和value封装为Node插入到链表的尾部,同时判断在插入新节点之前的链表节点个数是不是大于等于8,如果是,则将链表改为红黑树。
iii. 如果上述步骤中发现存在相同的key,则根据onlyIfAbsent标记是否需要更新value值,然后返回oldValue - modCount++
- HashMap的元素个数size加1
- 如果size大于扩容的阈值,则进行扩容
JDK8中HashMap的get方法实现过程
- 根据key生成hashcode
- 如果数组为空,则直接返回空
- 数组不为空,则利用hashcode和数组的长度通过逻辑与操作算出key所对应的数组下标i
- 如果数组的第i个位置上没有元素,则直接返回空
- 如果数组的第1个位置上的元素key等于get方法所传进来的key,则返回元素,并获取该元素的value
- 如果不等于则判断该元素还有没有下一个元素,如果没有,则返回空
- 如果有则判断该元素的类型是链表节点还是红黑树节点
a. 如果是链表则遍历链表
b. 如果是红黑树则遍历红黑树 - 找到则返回元素,找不到直接返回空
JDK7与JDK8中HashMap的不同点
- JDK8中使用了红黑树
- JDK7中链表使用了头插法(扩容转移元素的时候也使用头插法,头插法速度更快,无需遍历链表,但在多线程扩容的情况下使用头插法会出现循环链表的问题,导致CPU飙升)。JDK8中链表使用的是尾插法(JDK8中要去计算链表中节点的个数,需要遍历链表来获取总数,所以直接使用尾插法)
- JDK7的Hash算法比JDK8中的更复杂,Hash算法越复杂生成的hashcode则更散列,那么HashMap中的元素则更散列,更散列则HashMap的查询性能更好,JDK7中没有红黑树,所以只能优化Hash算法使得元素分布更散列,而JDK8中增加了红黑树,查询性能得到了保障,所以可以简化一下Hash算法,比较Hash算法越复杂就越消耗CPU
- 扩容过程中JDK7中有可能会重新对key进行哈希(重新Hash跟哈希种子有关系),而JDK8中没有这部分逻辑
- JDK8中扩容条件和JDK7中不一样,除开判断size是否大于阈值之外,JDK7中还判断了tab[i]是否为空,不为空的时候才进行扩容,而JDK8中则没有该条件
- JDK8还多了一个API:putIfAbsent(key,value)
- JDK7和JDK8扩容过程中转移元素的逻辑不一样,JDK7每次转移一个元素,JDK8是先算出来当前位置上哪些元素在新数组的低位上,哪些在新数组的高位上,然后在一次性转移
ConcurrentHashMap
JDK7中的ConcurrentHashMap是怎样保证并发安全的
主要利用Unsafe类操作+ReentrantLock+分段锁思想
主要使用了Unsafe类的一下方法:
1. compareAndSwapObject:通过CAS的方式修改对象的属性
2. putOrderedObject:并发安全的给数组的某个位置赋值
3. getObjectVolatile:并发安全的获取数组某个位置的元素
分段锁思想是为了提高ConcurrentHashMap的并发量,分段数越高则支持的最大并发量越高,开发者可通过concurrencyLevel参数来指定并发量。ConcurrentHashMap的内部类Segment就是用来表示某一段锁的。
每个Segment就是一个小型的HashMap,当调用ConcurrentHashMap的put方法时,最终会调用到Segment的put方法,而Segment类继承了ReentrantLock,所以Segment自带可重入锁,当调用到Segment的put方法时,会先利用可重入锁加锁,加锁成功后再将待插入的key和value插入到小型的HashMap中,插入完成后解锁。
JDK7中的ConcurrentHashMap的底层原理
ConcurrentHashMap底层是由两层嵌套数组实现的:
1. ConcurrentHashMap对象中有一个属性segments,类型Segment[]
2. Segment对象中有一个属性table,类型为HashEntry[]
当调用ConcurrentHashMap的put方法时,现根据key计算出对应的Segment[]数组下标j,确定好当前key和value应该插入到哪个Segment对象中,如果segments[j]为空,则利用自旋锁的方式在j位置上生成一个Segment对象
然后调用Segment对象的put方法
Segment对象的put方法会先加锁,然后根据key计算出所对应的HashEntry[]数组下标i,然后将key和value封装成HashEntry对象放入该位置,此过程和JDK7的HashMap的put方法一样,操作完成后解锁。
在加锁的过程中逻辑比较复杂,先通过自旋加锁,如果超过一定次数就会直接阻塞等等加锁。
JDK8中的ConcurrentHashMap是怎样保证并发安全的
主要利用了Unsafe类操作+synchronized关键字。
Unsafe类仍然和JDK7中类似,主要复杂并发安全的修改对象属性或数组某个位置的值。
synchronized主要负责在需要操作某个位置是进行加锁(该位置不为空),比如向某个位置的链表插入节点,向某个位置的红黑树插入节点。
JDK8中其实仍然有分段锁的思想,只不过JDK7中段数是可以控制的,而JDK8中是数组的每一个位置都有一把锁。
当向ConcurrentHashMap中put一个key、value时:
1. 首先根据key计算对应数组下标i,如果该位置没有元素,则通过自旋的方式去向该位置赋值。
2. 如果该位置有元素,则使用synchronized加锁
3. 加锁成功后,在判断该元素的类型
a. 如果是链接则添加节点到链表中
b. 如果是红黑树则添加节点到红黑树中
4. 添加成功后,判断是否需要进行树化
5. addCount,这个方法的意思的ConcurrentHashMap的元素个数加1,但是这个操作也是需要并发安全的,并且元素个数加1成功后,会继续判断是否要进行扩容,如需要,则会进行扩容,所以这个方法很重要
6. 同一个线程在put时如果发现当前ConcurrentHashMap正在进行扩容则会帮助扩容。
JDK7和JDK8中的ConcurrentHashMap的不同点
- JDK8中没有分段锁了,而是使用synchronized关键字来进行控制
- JDK8中的扩容性能更好,支持多线程同时扩容,实际上JDK7中也支持多线程扩容,因为JDK7中的扩容是针对每个Segment的,所以也可能多线程扩容,但是性能没有JDK8高,因为JDK8中对于任意一个线程都可以去帮助扩容。
- JDK8中的元素个数统计的实现也不一样了,JDK8中增加了CounterCell来帮助计数,而JDK7中没有,JDK7中是put的时候每个Segment内部计数,统计的时候是遍历每个Segment对象加锁统计