资料来源:https://www.bilibili.com/video/BV1VD4y1D7Q7?p=7
hashMap 1.7中的链表为什么采用头插法?
因为:头插法他是比较快的。
单线程:
多线程下会出现问题:
jdk7里面hashmap扩容的时候可能会导致循环链表的出现。
hashMap 在扩容的时候,若是多线程操作,则有可能出现循环链表。
如何避免:使用的时候尽量不要让它触发扩容机制,可以通过控制初始化大小和阈值来控制。
1.7的 ConcurrentHashMap 是线程安全的。
它的数据结构是一个 Segment[] ,然后数据里面的一个 HashEntity[] 数组。HashEntity 里面是一个链表。
它的 Segment数组的长度是确定的,扩容是发生在HashEntity[] 这个数组上的。使用的是CAS完成的内存操作。
红黑树定义:
1.8的 hashMap 是由数组+链表+红黑树组成的。
当进行添加的时候,会先按照单项链表的形式进行尾部追加。如果链表的长度>=8的话,就会把该链表变成双向链表并且树化。
在扩容的时候,链表会有一个高位与低位,实际上就是把一条链表拆分成了两条链表,一个放在扩容之后数组的 index 位置,另外一个放在 index + 原来table.length+index 的位置。
但是如果当前 table[index] 的位置上面是一颗树的话(其实隐藏了一个双向链表),也会先去获取一个高低位,如果有一个位置为 null。则就会把整颗树直接移动到 table[index] 的位置。否则该位置的数值<=6的话,就会把树拆分成两个单项链表,然后在移动到新的数组上。
5.JDK8中HashMap源码解析(下)P5 - 02:22:13
红黑树移除节点,实际上是先在隐藏的双向链表中把要删除的元素通过修改指针的形式把它移除掉。然后在根节点的基础上,把双向链表转化为单项链表。从而达到移除节点的功能。
1.8 ConcurrentHashMap 是一个 Node[] 数组组成的,里面是一个链表或者TreeBin(里面是红黑树)。
为什么是线程安全的,使用了 sychronized + cas。
[] 数组组成的,里面是一个链表或者TreeBin(里面是红黑树)。
为什么是线程安全的,使用了 sychronized + cas。
======================================
HashMap与ConcurrentHashMap面试要点
HashMap
HashMap底层数据结构
JDK7:数组+链表
JDK8:数组+链表+红黑树(JDK8中即使用了单项链表,也使用了双向链表,双向链表主要是为了链表操作方便,应该在插入,扩容,链表转红黑树,红黑树转链表的过程中都要操作链表)
JDK8中的HashMap为什么要使用红黑树?
当元素个数小于一个阈值时,链表整体的插入查询效率要高于红黑树,当元素个数大于此阈值时,链表整体的插入查询效率都要低于红黑树。此阈值在HashMap中为8。
JDK8中的HashMap什么时候将链表转化为红黑树?
这个题很容易答错,大部分答案就是:当链表中的元素个数大于8时就会把链表转化为红黑树。但是其实还有另外一个限制;当发现链表中的元素个数大于8之后,还会判断一下当前数组的长度,如果数组长度小于64是,此时并不会转化为红黑树,而是进行扩容。只有当链表中的个数大于8,并且数组的长度大于等于64时才会将链表转化为红黑树。
上面扩容的原因是:如果数组长度还比较小的时候,就会先利用扩容数组来缩小链表的长度。当数组的长度>=64的时候再去判断链表的长度是否>8个,满足以上两个条件才会出现红黑树。
JDK8中HashMap的put方法的实现过程?
- 根据key生成hashcode.
- 判断当前HashMap对象中的数组是否为空,如果为空则初始化该数组.
- 根据逻辑与运算,算出hashcode基于当前数组对应的数组下标 i .
- 判断数组的第 i 个位置的元素 (tab[i]) 是否为空.
- 如果为空,则将 key,value 封装为 Node 对象赋值给 tab[i] .
- 如果不为空:
- 如果 put 方法传入进来的 key 等于 tab[i].key,那么证明存在相同的 key .
- 如果不等于 tab[i].key,则:
- 如果 tab[i] 的类型是 TreeNode,则表示数组的第 i 位置上是一颗红黑树,那么将 key 和 value 插入到红黑树中,并且在插入之前会判断在红黑树中是否存在相同的 key .
- 如果 tab[i] 的类型不是 TreeNode,则表示数组的第 i 位置上是一个链表,那么遍历链表寻找是否存在相同的 key,并且在遍历的过程中会对链表中的节点进行技计数,当遍历到最后一个节点时,会将key,value封装为Node插入到链表的尾部,同时判断在插入新节点之前的链表节点个数是不是大于等于8,如果是,则将链表改为红黑树。
- 如果上述步骤中发现存在相同的 key,则根据 onlyIfAbsent 标记来判断是否需要更新 value 值,然后返回 oldValue .
- modCount++
- HashMap 的元素个数 size 加 1 .
- 如果 size 大于扩容的阈值,则进行扩容。
JDK8中HashMap的get方法的实现过程
- 根据 key 生成 hashcode
- 如果数组为空,则直接返回空
- 如果数组不为空,则利用 hashcode 和数组长度通过逻辑与操作算出 key 所对应的数组下标 i .
- 如果数组的第 i 个位置上没有元素,则直接返回空.
- 如果数组的第 i 个位置上的元素的 key 等于 get 方法所传进来的 key,则返回该元素,并获取该元素的 value.
- 如果不等于则判断该元素还有没有下一个元素,如果没有,返回空.
- 如果有则判断该元素的类型是链表结点还是红黑树结点:
- 如果是链表则遍历链表.
- 如果是红黑树则遍历红黑树.
- 找到即返回元素,没找到的则返回空
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 操作中的:
- compareAndSwapObject:通过 cas 的方式修改对象的属性.
- putOrderedObject:并发安全的给数组的某个位置赋值.
- getObjectVolatile:并发安全的获取数组某个位置的元素.
分段思想是为了提高 ConcurrentHashMap 的并发量,分段数越高则支持的最大并发量越高,程序员可以通过concurrencyLevel 参数来指定并发量。ConcurrentHashMap 的内部类 Segment 就是用来表达某一个段的。
每个 Segment 就是一个小型的 HashMap 的,当调用 ConcurrentHashMap 的 put 方法时,最终会调用到 Segment 的 put 方法,而 Segment 类继承了 ReentrantLock,所以 Segment 自带可重入锁,当调用到 Segment 的 put 方法时,会先利用可重入锁加锁,加锁成功后再将待插入的 key,value 插入到小型的 HashMap 中,插入完成后解锁。
JDK7中的ConcurrentHashMap的底层原理
ConcurrentHashMap 底层是由两层嵌套数组来实现的:
- ConcurrentHashMap 对象中有一个属性 segments,类型为 Segment[];
- 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 时,
- 首先根据 key 计算对应的数组下标 i,如果该位置没有元素,则通过自旋的方法区向该位置赋值。
- 如果该位置有元素,则 synchronized 会加锁。
- 加锁成功之后,再判断该元素的类型:
- 如果是链表节点,则添加到链表中。
- 如果是红黑树节点,则添加到红黑树中。
- 添加成功后,判断是否需要进行树化。
- addCount,这个方法的意思是 ConcurrentHashMap 的元素个数加 1,但是这个操作也是需要并发安全的,并且元素个数加 1 成功后,会继续判断是否要进行扩容,如果需要,则会进行扩容,所以这个方法很重要。
- 同时一个线程在 put 时如果发现当前 ConcurrentHashMap 正在进行扩容则会去帮助扩容。
JDK7和JDK8中的ConcurrentHashMap的不同点
这两个的不同点太多了…,既包括了 HashMap 中的不同点,也有其他不同点,比如:
- JDK8中没有分段锁了,而是使用 synchronized 来进行控制。
- JDK8中的扩容性能更高,支持多线程同时扩容,实际上JDK7中也支持多线程扩容,因为JDK7中的扩容是针对每个 Segment 的,所以也可能多线程扩容,但是性能没有 JDK8 高,因为 JDK8 中对于任意一个线程都可以去帮助扩容。
- JDK8中的元素个数统计的实现也不一样了,JDK8中增加了 CounterCell 来帮助技术,而JDK7中没有,JDK7中是 put 的时候每个 Segment 内部技术,统计的时候是遍历每个 Segment 对象加锁统计(当然有一点点小小的优化措施)。