x mod 2^n = x & (2^n - 1)

1. 拿到 key 的 hashCode 值
2. 将 hashCode 的高位参与运算，重新计算 hash 值
3. 将计算出来的 hash 值与 (table.length - 1) 进行 & 运算

数据结构

1.B树 和 B+树

• B树叶子节点可以存放多个元素
• B+树的叶子节点之间是有指针的

红黑树

1. (1) 每个节点或者是黑色，或者是红色。
2. (2) 根节点是黑色。
3. (3) 每个叶子节点是黑色。 [注意：这里叶子节点，是指为空的叶子节点！]
4. (4) 如果一个节点是红色的，则它的子节点必须是黑色的。
5. (5) 从一个节点到该节点的子孙节点的所有路径上包含相同数目的黑节点。

HashMap 的底层是个 Node 数组（Node<K,V>[]
table），在数组的具体索引位置，如果存在多个节点，则可能是以链表或红黑树的形式存在。

增加、删除、查找键值对时，定位到哈希桶数组的位置是很关键的一步，源码中是通过下面3个操作来完成这一步：

• 1）拿到 key 的 hashCode 值；
• 2）将 hashCode 的高位参与运算，重新计算 hash 值；
• 3）将计算出来的
  hash 值与 “table.length - 1” 进行 & 运算。
• HashMap 的默认初始容量（capacity）是 16，capacity 必须为 2 的幂次方；默认负载因子（load factor）是 0.75；实际能存放的节点个数（threshold，即触发扩容的阈值）= capacity * load factor。

HashMap 在触发扩容后，阈值会变为原来的 2 倍，并且会对所有节点进行重 hash 分布，重 hash
分布后节点的新分布位置只可能有两个：“原索引位置” 或 “原索引+oldCap位置”。例如 capacity 为16，索引位置 5
的节点扩容后，只可能分布在新表 “索引位置5” 和 “索引位置21（5+16）”。

导致 HashMap 扩容后，同一个索引位置的节点重 hash 最多分布在两个位置的根本原因是：
1）table的长度始终为 2 的 n 次方；
2）索引位置的计算方法为 “(table.length - 1) & hash”。HashMap 扩容是一个比较耗时的操作，定义HashMap 时尽量给个接近的初始容量值。

• HashMap 有 threshold 属性和 loadFactor 属性，但是没有 capacity 属性。初始化时，如果传了初始化容量值，该值是存在 threshold 变量，并且 Node 数组是在第一次 put
  时才会进行初始化，初始化时会将此时的 threshold 值作为新表的 capacity 值，然后用 capacity 和loadFactor 计算新表的真正 threshold 值。
• 当同一个索引位置的节点在增加后达到 9 个时，并且此时数组的长度大于等于 64，则会触发链表节点（Node）转红黑树节点（TreeNode），转成红黑树节点后，其实链表的结构还存在，通过 next属性维持。链表节点转红黑树节点的具体方法为源码中的 treeifyBin方法。而如果数组长度小于64，则不会触发链表转红黑树，而是会进行扩容。
• 当同一个索引位置的节点在移除后达到 6 个时，并且该索引位置的节点为红黑树节点，会触发红黑树节点转链表节点。红黑树节点转链表节点的具体方法为源码中的 untreeify 方法。
• HashMap 在 JDK 1.8 之后不再有死循环的问题，JDK 1.8 之前存在死循环的根本原因是在扩容后同一索引位置的节点顺序会反掉。
• HashMap 是非线程安全的，在并发场景下使用 ConcurrentHashMap 来代替。