HashMap底层原理 | HashMap源码笔记

1.8之后的hashMap底层结构

采用数组加链表，当数组超过64而且链表长度超过8就会扩容成红黑树，当链表退化为6以下，就会退化为链表。当链表超过8但是数组没有64的时候，就会进行散列扩容，扩大数组重新进行哈希计算下标，让链表变短

1.7和1.8的区别

JDK 1.7和1.8版本下HashMap的实现存在一些不同，其中最重要的改变是在HashMap的内部实现上。

1. 内部实现：在JDK 1.7中，HashMap采用数组+链表的形式来存储元素，即在数组中存储链表的头节点，当出现hash冲突时，则将新元素插入到对应位置的链表尾部。在JDK 1.8中，当链表长度达到一定程度时，会将链表转换为红黑树来提高查找效率，即在数组中存储红黑树的根节点。

2. hash算法：在JDK 1.7中，HashMap的hash算法中只考虑了元素的key值的hashCode方法的返回值，而在JDK 1.8中，除了考虑key值的hashCode方法的返回值外，还会使用一些位运算等操作，以期进一步降低hash冲突的概率。

3. 并发性：在JDK 1.7中，当多个线程同时对HashMap进行插入、删除等操作时，可能会导致链表成环等问题，从而造成死循环等错误。在JDK 1.8中，HashMap使用了一些锁的机制，例如synchronized和CAS，来保证并发性的正确性。

综上所述，JDK 1.8相较于JDK 1.7，在HashMap的实现上做了一些改进，包括内部实现、hash算法和并发性等方面。这些改进使得HashMap在使用中更加高效和可靠。

为什么采用红黑树

HashMap底层采用红黑树而不是其他二叉搜索树，主要是因为红黑树有更好的性能特征，可以在大多数情况下提供更好的性能保证。

以下是一些红黑树的性能特点：

1. 平衡性：红黑树是一种自平衡二叉搜索树，能够保证在最坏情况下，树的高度不会超过2log(n+1)个节点，其中n为节点数。这使得红黑树的查找、插入和删除等操作的时间复杂度均为O(log n)，在最坏情况下也不会超过O(log n)。

2. 插入和删除性能好：相较于其他自平衡二叉搜索树，红黑树的插入和删除性能更好，因为红黑树的旋转操作比较简单，并且节点的颜色标记可以通过颜色翻转和颜色转移等技术来简化。

3. 顺序性能好：红黑树保持节点的左右子树高度差不超过1，因此它的中序遍历结果是有序的，可以用于实现有序映射或有序集合等数据结构。

因此，HashMap底层采用红黑树可以在保证性能的同时，提供有序性能好的数据结构。

什么时候数组会扩容

当数组的长度超过负载因子的时候默认0.75，而且还有一个条件：必须是当前计算出来的下标位置是有元素的非空，我们才扩容，如果是空，那么还是直接插入不扩容。

HashMap数组插入元素和扩容是怎么找下标的

这就是hashMap底层找存放到哪个位置的原理，因为底层是通过hash随机值用length-1的长度进行与运算算出来的下标，为什么用位运算不用取余，因为更快。

与运算所以得让length-1为2的幂次方这样-1之后比如15,31这种前面位都是0后面位都是1，这样才能随机的分散得数组各个位置，如果是16进行算，都是0，那么只能存到0或者16的位置上了

而且当我们扩容变成2倍之后，我们重新hash算出来的值，比如原本是16，扩容32，原本下标1，那么扩容后下标就16，他是重新对他这个length-1进行&，这样就31就比15多了一个1但是hash随机的值可能是0和1那么与就等于把原本位置拆分，所以原本1位置的元素会分散到1和16上，其他位置也是一样只会到+16的位置上，这样就平均分散开了，太神奇了

15对应2进制0000 1111

16对应2进制0001 0000

31对应2进制0001 1111

32对应2进制0010 0000

所以一定是2的幂次方这个数组的长度，就算用构造函数定义了10，他也会找大于10的最大2的幂次方16（源码截图：我们会把10传入这个方法）

什么时候会重新哈希

默认重新哈希的种子是0，这样执行冲哈希是不会有结果的，只有当数组的容量，当扩容的时候就可能会重新进行重新哈希计算，看有没有超过这个值（取配置，这个重新哈希的阈值是可以配的，默认情况下阈值是Integer的最大值）所以默认情况下是很难触发重新哈希的。

modcount是什么意思，有什么用

有个快速失败的机制，我们用for循环来修改hashmap，第一次遍历修改完成后成功，第二次遍历直接报错，并发修改错误，为什么呢？

其实就是modcount底层起的作用，我们可能有的线程在遍历hashmap，另一个线程在修改，那么

hashmap不是线程安全的，但是不能不做任何的处理，那么他是怎么处理的呢？我们遍历的时候就会先判断到假如modcount=2，那么我们修改够modcount就会变成3（每次我们修改插入或删除都会对modcount进行++），我们一旦发现这个modcound发生改变就知道有其他线程在用，我们就直接抛出并发异常。我是线程不安全的，所以线程1就直接报错，（每次在取元素的时候都会去判断一下modcount和之前记录的expectmodcount是不是相等的）

二次哈希

算hashcode的时候不是直接用key进行hash就和length-1的15进行&，而是拿到这个key哈希出来的结果再进行右移16位然后再与这个结果异或，因为如果直接拿key哈希完后的hashcode来与，前面是没有参与的，这样做可以让前后都异或之后再与，这样可以减少哈希冲突

如题上面是右移前的hash，下面是移动后的，然后让他们异或就能算出前后都使用的hashcode再来与运算，从而减少哈希冲突

因为原本直接算的话只能让后面的4个参与，前面的是参与不了的，现在这样才能让前后都参与