作为Java中重要的数据结构，Hashmap不仅用于正常工作，而且在访谈中起着重要作用。今天，我将带您从源代码的角度重新理解我们常用的hashmap。
从JDK7转换为JDK8时，实现也发生了很大变化。让我们首先看一下他们的差异：
首先，查看存储结构。如果您更不熟悉红色和黑树，则可以首先查看完全平衡的二进制树（AVL）和红树的相关知识。这里只是红树和黑树的某些性能特征：
Hashmap中的JDK7，我们最常用的操作可能是使用的，但是您是否真的了解其实施的原理？看看PUT操作的核心代码：
一般来说，它包含三个操作：
1.计算密钥中引入的值
2.通过该方法计算标签值
3.添加链接列表并将其放入相应的阵列招标中
请注意，我们分配给值的第三部分，即将节点插入到头节点，然后将原始链接列表直接连接到我们新插入的节点。
顺便说一句，hashmap支持键空，并且存储在数组的0位置的元素只能具有一个元素，并且在0位置中没有数组。
操作相对简单。首先找到数组的设置，然后比较键是否与给定的键相同。特定方法，遍历等于哈希值是否等于以及键是否等于。
由于称为hashmap，因此计算哈希值必须是必要的部分。首先查看JDK7中的hashmap方法：
在这方面，我们暂时不看哈希种子，我们可以在计算中看到大量正确的换档操作，那么为什么您需要正确移动呢？这是考虑碰撞问题。我在计算出价阵列之前提到的：
这样，hashmap的长度必须是次要数字，在其初始化和扩展方面受到限制。在计算下表时，次级两个-square -way -nigus 1的数量可以确保其二进制数字的后面数字都是1，很容易计算出价。
例如，哈希图的长度为16，因此计算出的哈希值和0000 1111是完成和计算的，只需要获取最后四位，并且可以实现下属竞标的计算。该操作比其余操作快。
返回上面，继续谈论为什么需要大量正确的手动操作，或者在长度16中，如果多个密钥计算的哈希值是：
我们发现，只要后四个是相同的，哈希值是相同的，碰撞很高，因此，在此时，引入了正确的运动以允许高位置参与和计算。并减少链接列表的长度。
红树和黑树是在JDK8JDK8中引入的，但这并不意味着不存在链接列表。检查源代码。我们可以找到两个非常关键的值：
当链接列表的元素超过8时，它将自动变成红色和黑树。当红树和黑树节点的数量小于6时，它将返回到链接列表。
查看操作：
阅读此代码后，我们了解为什么JDK8使用尾插入方法。由于在判断链接列表或红色和黑树的过程中，有必要确定是否需要8个元素，并且您需要在至少一次。因此，可以将新元素直接插入尾部节点。
一般思想的方法没有改变。计算出价，然后穿越。这只是判断它是试验链接列表存储还是红色和黑色树存储步骤的步骤，而不是JDK7。
JDK8还简化其算法：
右边只有16位，简化了哈希算法，并用红色和黑树提高查询的效率。
最后，看看两者的扩展操作。扩展是为了扩展数组，而不是链接或黑色的树。阵列初始化时数组的默认长度为16，而在存储存储时元素存储时发生的哈希碰撞发生了很多。目的我们的扩展是缩短长链接列表的长度并提高查询的效率。
由于容量的源代码相对较长，因此在这里没有发布，因此仅列出了核心想法。
在JDK7中：
只有当数字大于阈值并且当前插入位置不是空的时，容量会扩大，并且容量为2倍。
将旧表转移到新表格时，您需要重新计算阵列的竞标。
扩展后，重新计算出价。以16的扩展为例：
容量扩展后，阵列可能会更改或不变。这次，扩展的哈希值为1或0，如果是1，则0是相同的。但是在此过程中，死锁的问题可能是引起。
JDK8：
在JDK8扩展中，为了避免前面提到的死锁的问题，可以改善容量扩展方法。通过判断这1位为0或1，它是0或1，如果是1，则是1，如果是1，加上原始数量数组。
总结：
如果您认为这对您有帮助，您的朋友可以喜欢并转发它。非常感谢
公共帐户，加一个朋友，并赞美