1. HashMap

1. 前言

• hashMap是JDK中的哈希表的容器的实现，它通过使用CPU计算替代遍历寻址来提高数据搜索的速度。
• 这种结构的时间复杂度通常是O(1)，也就是说它不会随着数据量的增加而降低他的遍历速度，当然这是指在没有发生hash冲突的情况下。

2. 数据结构

• 哈希表的实现有很多种，有纯数组的实现，也有数组加链表的实现，还有数组加上额外内存区域的实现，这些实现都各有各的好处，而JDK选择了其中较为简单的一种实现，即数组加链表的实现方式。
• 更加精确点来说，在JDK1.8之前的版本是数组加链表，而JDK1.9之后的版本是数组加红黑树的结构

1.8的数据结构

• JDK1.8添加的红黑树结构的实现，主要是为了降低哈希冲突的带来的影响。

3. 搜索数据

• 接下来说一下Hashmap如何搜索数据，哈希表这种数据结构最重要的便是它的哈希算法，哈希算法通过哈希key值，来为数据做索引，将数据导航到指定的存储位置，并且不管怎么计算，数值都应该是一样的才能够命中缓存。

3.1 哈希算法

3.1.1 哈希值的获取

• HashMap使用的哈希值直接使用实例对象的hashcode()方法获取的哈希值。
• 这个hashcode()方法的实现可以直接使用JDK默认的实现，我们也可以通过重写实现，其中JDK默认的实现有部分逻辑是直接获取的内存地址，也有其他的实现，具体要看JDK的源码怎么编写。

3.1.2 与运算替代求余运算

• HashMap在获取完实例对象的哈希值之后，不管是1.7还是1.8都会通过与（容量-1）的操作来定位数据的存储位置。
• 这是因为HashMap为了提高哈希速度，它抛弃了求余的方式，选择使用效率更高的与操作。
• 但是这种与操作有个限制便是需要容量是2的n次幂才行，所以一般我们创建HashMap的时候虽然指定了HashMap的容量，但是HashMap会自动向上取到2的n次幂。

3.1.3 高位扰乱低位

• 接下来需要说一下1.8的哈希算法的特殊处理，1.8在获取到Hash值之后，首先会将前面一半的位数和后面一半的位数进行异或操作，添加数据的扰乱程度，之后再让让高位的数据和低位的数据一同参与到运算中，使哈希更加平均。

3.2 添加数据

• 接下来说一下HashMap如何添加数据，哈希表的结构为一个数组加链表，且一开始的时候是一个空数组，在第一次添加数据的时候会进行resize()操作，而这一次resize操作主要是为了初始化数组，数组的大小为初始容量向上取整到2的大小。

3.2.1 添加数据

• 当第一个数据添加的时候，数据首先通过哈希算法找到槽位，也就是数组上的对应一个节点，然后链表节点的形式放到槽位上，其他数据也是一样放置到对应的槽点上。

3.2.2 哈希冲突

• 但是数据量无穷无尽，槽位却是限定的，那么总会有两个不同数据会哈希到同一个数值，此时两个数据要使用同一个槽位的方式便叫做哈希冲突。
• 解决哈希冲突的方式有很多，像是如果发现冲突就往后挪动一位槽为进行存储，或者划定一块特定的区域来存储这些冲突数据。这些方案实现上都有其优缺点。
• 而HashMap采用的是最简单的方式，即直接使用链表的方式将冲突的数据进行串联，形成一条链表，这样当搜索该槽位上的数据的时候，就会遍历槽位上的链表，将数据搜索出来；
• 显然这样解决了哈希冲突，但是却会出现另一个问题，该槽位上的哈希冲突过多，对导致链表过长，导致搜索速度变慢；
• 对于这种情况，hashMap提供了resize方案来解决这个问题，同时在1.8的时候引入红黑树来解决问题。

3.2.3 链表与红黑树

• 先说一下1.8如果引入红黑树解决链表过长的问题。
• 链表之所以会导致搜索速度变慢，主要是因为其数据结构决定了他的遍历速度只能是O(n)，所以通过引入红黑树的结构，时间复杂度便能够降低为O(log^n)，随着链表的数据量和红黑树的数据量增大，两者的遍历速度将不断拉大。
• JDK1.8中使用的是链表加红黑树，而不是红黑树替代链表的方案，主要是因为红黑树的维护成本相对与链表是较高的，而生活中大多数的场景下，单个槽位上的冲突数并不会很多，红黑树的高效查询特性并不能凸显出来，因此一开始发生冲突的时候，仍然使用链表来处理哈希冲突问题。
• 而当槽位上的冲突数增加达到8的时候，HashMap便启用链表转换成红黑树的树化逻辑。不过这有一个前提，便是HashMap的槽位数量大于64，否则HashMap倾向于通过resize来增加槽位，缓解哈希冲突问题。
• 而当槽位上的冲突树减少达到6的时候，HashMap便启用红黑树转换成链表的链表化逻辑，为什么树化和链表化的阈值不同主要是为了防止频繁put和remove同一个值而导致频繁的转换，使HashMap的性能消耗在一些不必要的逻辑上，这相当于一个缓冲带的作用。

3.2.4 resize

• 接下来说resize方案，我们知道HashMap会根据初始容量创建一定的槽位，而槽位的数量会影响到哈希冲突的概率，而resize便是通过增加槽位来降低哈希冲突的概率；
• 当槽位链表上的冲突数达到8而数组容量还没达到64，或HashMap上存储的数据达到当前的阈值0.75倍容量时，就会触发resize操作；
• HashMap的resize方案是首先创建两倍容量的数组，为什么是两倍是因为哈希算法已经限定了只能是2的n次幂个槽位，不再赘述。
• 之后遍历每个槽位上的链表，以尾插法的方式将链表插入到数组上，其中转移的过程中直接将key与resize之后的容量，如果是0则槽位位置不变，如果是1则槽位的值添加resize一半容量的数值。
• 需要特别说明的是，1.7使用的resize方案中，是用头插法的方式插入到新的数组中，并且在线程冲突的情况下会发生链表死循环的情况。
• 不过hashMap本身就是线程不安全的容器，不管1.8还是1.7都是不允许在线程不安全的环境下使用的。