标签：def key 为什么 oat 数组下标 length access next post
HashMap基于Map接口实现，元素以键值对的方式存储，并允许使用null键和null值，但只能有一个键作为null，因为key不允许重复，另外HashMap不能保证放入元素的数据，它是无序的，和放入的顺序并不能相同，HashMap是线程不安全的。
public class HashMap<K,V>extends AbstractMap<K,V>
implements Map<K,V>, Cloneable, Serializable
static final int DEFAULT_INITIAL_CAPACITY = 1 << 4; //默认初始化大小 16
static final float DEFAULT_LOAD_FACTOR = 0.75f; //负载因子0.75
static final Entry<?,?>[] EMPTY_TABLE = {}; //初始化的默认数组
transient int size; //HashMap中元素的数量
int threshold; //判断是否需要调整HashMap的容量
HashMap有数组和链表来实现对数据的存储，HashMap采用Entry数组来存储key-value对，每一个键值对组成了一个Entry实体，Entry类实际上是一个单向的链表结构，它具有Next指针，可以链接下一个Entry实体，以次来解决Hash冲突的问题。
数组存储区间是连续的，占用内存严重，故空间复杂的很大。但数组的二分查找时间复杂度小，为O(1)；数组的特点是：寻址容易，插入和删除困难；
链表存储区间离散，占用内存比较宽松，故空间复杂度小，但时间复杂度很大，达 O(N) 。链表的特点是：寻址困难，插入和删除容易。
从上图可以发现数组结构是由数组+链表组成，一个长度为16的数组中，每个元素存储的是一个链表的头节点。那么这些元素是按照什么样的规矩存储到数组中？
通过hash(key.hashCode())%length 获得，也就是元素的key的哈希值对数组长度取模得到。比如上述哈希表中，12%16=12,28%16=12,108%16=12,140%16=12。所以12、28、108以及140都存储在数组下标为12的位置。
取模运算的方式固然简单，但是效率很低。为了实现高效的HashMao算法，HashMap的发明者采用了位运算的方式。
公式： index = HashCode（Key） & （Length - 1）
以值为“book”的key来演示整个过程：
1.计算book的hashcode，结果为十进制的3029737，二进制的101110001110101110 1001。
2.假定HashMap长度是默认的16，计算Length-1的结果为十进制的15，二进制的1111。
3.把以上两个结果做与运算，101110001110101110 1001 & 1111 = 1001，十进制是9，所以 index=9。
可以说，Hash算法最终得到的index结果，完全取决于Key的Hashcode值的最后几位。
这样做不但效果上等同于取模，而且还大大提升了性能。
HashMap里面实现一个静态内部类Entry，其重要的属性有 hash，key，value，next。
HashMap里面用到链式数据结构的一个概念。上面我们提到过Entry类里面有一个next属性，作用是指向下一个Entry。打个比方， 第一个键值对A进来，通过计算其key的hash得到的index=0，记做:Entry[0] = A。一会后又进来一个键值对B，通过计算其index也等于0，现在怎么办？HashMap会这样做:B.next = A,Entry[0] = B,如果又进来C,index也等于0,那么C.next = B,Entry[0] = C；这样我们发现index=0的地方其实存取了A,B,C三个键值对,他们通过next这个属性链接在一起。
比如调用 hashMap.put("apple", 0) ，插入一个Key为“apple"的元素。这时候我们需要利用一个哈希函数来确定Entry的插入位置（index）：
假定最后计算出的index是2，那么结果如下：
但是，因为HashMap的长度是有限的，当插入的Entry越来越多时，再完美的Hash函数也难免会出现index冲突的情况。比如下面这样：
可以利用链表来解决。
HashMap数组的每一个元素不止是一个Entry对象，也是一个链表的头节点。每一个Entry对象通过Next指针指向它的下一个Entry节点。当新来的Entry映射到冲突的数组位置时，只需要插入到对应的链表即可：
需要注意的是，新来的Entry节点插入链表时，使用的是“头插法”。
首先会把输入的Key做一次Hash映射，得到对应的index：
由于刚才所说的Hash冲突，同一个位置有可能匹配到多个Entry，这时候就需要顺着对应链表的头节点，一个一个向下来查找。假设我要查找的Key是“apple”：
第一步，查看的是头节点Entry6，Entry6的Key是banana，显然不是我要找的结果。
第二步，查看的是Next节点Entry1，Entry1的Key是apple，正是我要找的结果。
之所以把Entry6放在头节点，是因为HashMap的发明者认为，后插入的Entry被查找的可能性更大。
HashMap的容量是有限的。当经过多次元素插入，使得HashMap达到一定饱和度时，Key映射位置发生冲突的几率会逐渐提高。
这时候，HashMap需要扩展它的长度，也就是进行Resize。
影响发生Resize的因素有两个：
1.Capacity
HashMap的当前长度。HashMap的长度是2的幂。
2.LoadFactor
HashMap负载因子，默认值为0.75f。
衡量HashMap是否进行Resize的条件如下：
*HashMap.Size >= Capacity LoadFactor
HashMap的Rezie不是简单的吧长度扩大，而是经过两个步骤
1.扩容
创建一个新的Entry空数组，长度是原数组的2倍。
2.ReHash
遍历原Entry数组，把所有的Entry重新Hash到新数组。为什么要重新Hash呢？因为长度扩大以后，Hash的规则也随之改变。
回顾一下Hash公式：
index = HashCode（Key） & （Length - 1）
当原数组长度为8时，Hash运算是和111B做与运算；新数组长度为16，Hash运算是和1111B做与运算。Hash结果显然不同。
Resize前的HashMap：
Resize后的HashMap：
ReHash的Java代码如下：
/**
* Transfers all entries from current table to newTable.
*/
void transfer(Entry[] newTable, boolean rehash) {
int newCapacity = newTable.length;
for (Entry<K,V> e : table) {
while(null != e) {
Entry<K,V> next = e.next;
if (rehash) {
e.hash = null == e.key ? 0 : hash(e.key);
}
int i = indexFor(e.hash, newCapacity);
e.next = newTable[i];
newTable[i] = e;
e = next;
}
}
}
单线程下执行没有问题，多线程下的Rehash有问题！
假设一个HashMap已经到了Resize的临界点。此时有两个线程A和B，在同一时刻对HashMap进行Put操作：
此时达到Resize条件，两个线程各自进行Rezie的第一步，也就是扩容：
这时候，两个线程都走到了ReHash的步骤。回顾一下ReHash的代码：
假如此时线程B遍历到Entry3对象，刚执行完红框里的这行代码，线程就被挂起。对于线程B来说：
e = Entry3
next = Entry2
这时候线程A畅通无阻地进行着Rehash，当ReHash完成后，结果如下（图中的e和next，代表线程B的两个引用）：
直到这一步，看起来没什么毛病。接下来线程B恢复，继续执行属于它自己的ReHash。线程B刚才的状态是：
e = Entry3
next = Entry2
当执行到上面这一行时，显然 i = 3，因为刚才线程A对于Entry3的hash结果也是3。
我们继续执行到这两行，Entry3放入了线程B的数组下标为3的位置，并且e指向了Entry2。此时e和next的指向如下：
e = Entry2
next = Entry2
整体情况如图所示：
接着是新一轮循环，又执行到红框内的代码行：
e = Entry2
next = Entry3
整体情况如图所示：
接下来执行下面的三行，用头插法把Entry2插入到了线程B的数组的头结点：
整体情况如图所示：
第三次循环开始，又执行到红框的代码：
e = Entry3
next = Entry3.next = null
最后一步，当我们执行下面这一行的时候 !
newTable[i] = Entry2
e = Entry3
Entry2.next = Entry3
Entry3.next = Entry2
链表出现了环形！
整体情况如图所示：
此时，问题还没有直接产生。当调用Get查找一个不存在的Key，而这个Key的Hash结果恰好等于3的时候，由于位置3带有环形链表，所以程序将会进入死循环！
在高并发下通常使用ConcurrentHashMap，这个集合类兼顾了线程安全和性能。
总结：
1.Hashmap在插入元素过多的时候需要进行Resize，Resize的条件是
HashMap.Size >= Capacity * LoadFactor。
2.Hashmap的Resize包含扩容和ReHash两个步骤，ReHash在并发的情况下可能会形成链表环。
在Jdk1.8中HashMap的实现方式做了一些改变，但是基本思想还是没有变得，只是在一些地方做了优化，数据结构的存储由数组+链表的方式，变化为数组+链表+红黑树的存储方式，当链表长度超过阈值（8）时，将链表转换为红黑树。在性能上进一步得到提升。
执行构造函数，当我们看到这个new，第一反应应该是在堆内存里开辟了一块空间。
Map<String,Object> map = new HashMap<String,Object>();
构造方法：
public HashMap() {
this.loadFactor = DEFAULT_LOAD_FACTOR; // all other fields defaulted
}
初始化了一个负载因子
static final float DEFAULT_LOAD_FACTOR = 0.75f;
负载因子默认为0.75f
transient Node<K,V>[] table;
看到了数组，数组里原对象是Node，来看下
static class Node<K,V> implements Map.Entry<K,V> {
final int hash;
final K key;
V value; //key,value,用来存储put的key，value值的
Node<K,V> next; // next ，用来标记下一个元素
Node(int hash, K key, V value, Node<K,V> next) {
this.hash = hash;
this.key = key;
this.value = value; //构造函数
this.next = next;
}
put方法解析：
public V put(K key, V value) {
//调用putVal()方法完成
return putVal(hash(key), key, value, false, true);
}
final V putVal(int hash, K key, V value, boolean onlyIfAbsent,
boolean evict) {
Node<K,V>[] tab; Node<K,V> p; int n, i;
//判断table是否初始化，否则初始化操作
if ((tab = table) == null || (n = tab.length) == 0)
n = (tab = resize()).length;
//计算存储的索引位置，如果没有元素，直接赋值
if ((p = tab[i = (n - 1) & hash]) == null)
tab[i] = newNode(hash, key, value, null);
else {
Node<K,V> e; K k;
//节点若已经存在，执行赋值操作
if (p.hash == hash &&
((k = p.key) == key || (key != null && key.equals(k))))
e = p;
//判断链表是否是红黑树
else if (p instanceof TreeNode)
//红黑树对象操作
e = ((TreeNode<K,V>)p).putTreeVal(this, tab, hash, key, value);
else {
//为链表，
for (int binCount = 0; ; ++binCount) {
if ((e = p.next) == null) {
p.next = newNode(hash, key, value, null);
//链表长度8，将链表转化为红黑树存储
if (binCount >= TREEIFY_THRESHOLD - 1) // -1 for 1st
treeifyBin(tab, hash);
break;
}
//key存在，直接覆盖
if (e.hash == hash &&
((k = e.key) == key || (key != null && key.equals(k))))
break;
p = e;
}
}
if (e != null) { // existing mapping for key
V oldValue = e.value;
if (!onlyIfAbsent || oldValue == null)
e.value = value;
afterNodeAccess(e);
return oldValue;
}
}
//记录修改次数
++modCount;
//判断是否需要扩容
if (++size > threshold)
resize();
//空操作
afterNodeInsertion(evict);
return null;
}
如果存在key节点，返回旧值，如果不存在则返回Null。
首先需要理解二叉查找树（Binary Search Tree）
二叉查找树（BST）具备的特性
1.左子树上所有结点的值均小于或等于它的根结点的值。
2.右子树上所有结点的值均大于或等于它的根结点的值。
3.左、右子树也分别为二叉排序树。
下图中这棵树，就是一颗典型的二叉查找树：
比如我要查找值为10的节点：
1、查看根节点9：
2、由于10 > 9，因此查看右孩子13：
3、由于10 < 13，因此查看左孩子11：
4.由于10 < 11，因此查看左孩子10，发现10正是要查找的节点：
这种方式正是二分查找的思想，查找所需的最大次数等同于二叉查找树的高度。
在插入节点的时候也是利用类似的方法，通过一层一层比较大小，找到新节点适合插入的位置。
但二叉查找树存在缺陷，如：
假设初始的二叉查找树只有三个节点，根节点值为9，左孩子值为8，右孩子值为12：
接下来我们依次插入如下五个节点：7,6,5,4,3。依照二叉查找树的特性，结果会变成如下这样：
这样的形态虽然也符合二叉查找树的特性，但是查找的性能大打折扣，几乎变成的线性。
如何解决二叉查找树多次插入新节点而导致的不平衡？红黑树应运而生了。
红黑树（Red Black Tree） 是一种自平衡的二叉查找树。除了符合二叉查找树的基本特性外，它还具备下列的附加特性：
1、节点是红色或黑色。
2、根节点是黑色。
3、每个叶子节点都是黑色的空节点（NIL节点）。
4 、每个红色节点的两个子节点都是黑色。(从每个叶子到根的所有路径上不能有两个连续的红色节点)
5、从任一节点到其每个叶子的所有路径都包含相同数目的黑色节点。
这张图就是典型的红黑树！
正是因为这些规矩限制，才保证了红黑树的自平衡。红黑树从根到叶子的最长路径不会超过最短路径的2倍。
当插入或删除节点的时候，红黑树的规则有可能被打破。这时候就需要做出一些调整，来继续维持我们的规则。
什么情况下会破坏红黑树的规则，什么情况下不会破坏规则呢？举两个简单的例子：
1、向原红黑树插入值为14的新节点：
由于父节点15是黑色节点，因此这种情况并不会破坏红黑树的规则，无需做任何调整。
2、向原红黑树插入值为21的新节点：
由于父节点22是红色节点，因此这种情况打破了红黑树的规则4（每个红色节点的两个子节点都是黑色），必须进行调整，使之重新符合红黑树的规则。
调整有两种方法：[变色]和[旋转]。而旋转又分成了两种形式：[左旋转]和[右旋转]。
变色
为了重新符合红黑树的规则，尝试把红色节点变为黑色，或者把黑色节点变为红色。
下图所表示的是红黑树的一部分，需要注意节点25并非根节点。因为节点21和节点22连续出现了红色，不符合规则4，所以把节点22从红色变成黑色：
但这样并不算完，因为凭空多出的黑色节点打破了规则5，所以发生连锁反应，需要继续把节点25从黑色变成红色：
此时仍然没有结束，因为节点25和节点27又形成了两个连续的红色节点，需要继续把节点27从红色变成黑色：
左旋转：
逆时针旋转红黑树的两个节点，使得父节点被自己的右孩子取代，而自己成为自己的左孩子。看下图：
图中，身为右孩子的Y取代了X的位置，而X变成了自己的左孩子。此为左旋转。
右旋转：
顺时针旋转红黑树的两个节点，使得父节点被自己的左孩子取代，而自己成为自己的右孩子。看下图：
图中，身为左孩子的Y取代了X的位置，而X变成了自己的右孩子。此为右旋转。
红黑树的插入和删除包含很多种情况，每一种情况都有不同的处理方式。在这里举个典型的例子，体会一下！
我们以刚才插入节点21的情况为例：
首先，我们需要做的是变色，把节点25及其下方的节点变色：
此时 节点17 和 节点25 是连续的两个红色节点，那么把节点17变成黑色节点？恐怕不合适。这样一来不但打破了规则4，而且根据规则2（根节点是黑色），也不可能把节点13变成红色节点。
变色已无法解决问题，把节点13看着X，把节点17看着Y，想刚才的示意图那样进行左旋转：
由于根节点必须是黑色节点，所以需要变色，变色结果如下：
这样就结束了吗？并没有。因为其中两条路径(17 -> 8 -> 6 -> NIL)的黑色节点个数是4，其他路径的黑色节点个数是3，不符合规则5。
这时候我们需要把节点13看做X，节点8看做Y，像刚才的示意图那样进行右旋转：
最后根据规则来进行变色：
如此一来，红黑树变得重新符合规矩。 这一个例子的调整过程比较复杂，经历了如下步骤： 变色 -> 左旋转 -> 变色 -> 右旋转 -> 变色
红黑树的应用有很多，除了HashMap，jdk 的集合类TreeMap和TreeSet 底层就是红黑树实现的。
几点说明：
1、关于红黑树自平衡的调整，插入和删除节点的时候都涉及到很多种Case，由于篇幅原因无法展开来一一列举，有兴趣的朋友可以参考维基百科，里面讲的非常清晰。
2、红黑树调整过程的示例是一种比较复杂的情形，没太看明白的小伙伴也不必钻牛角尖，关键要懂得红黑树自平衡调整的主体思想。
参考文章
https://juejin.im/post/5a27c6946fb9a04509096248
https://zhuanlan.zhihu.com/p/28501879
https://blog.csdn.net/qq_41345773/article/details/92066554
标签：def key 为什么 oat 数组下标 length access next post
原文地址：https://www.cnblogs.com/yslss/p/13038699.html
