共计 10033 个字符，预计需要花费 26 分钟才能阅读完成。
1. HashMap 的底层数据结构是什么？
在 JDK1.7 中和 JDK1.8 中有所区别：
在 JDK1.7 中，由”数组 + 链表“组成，数组是 HashMap 的主体，链表则是次要为了解决哈希抵触而存在的。
在 JDK1.8 中，有“数组 + 链表 + 红黑树”组成。当链表过长，则会重大影响 HashMap 的性能，红黑树搜寻工夫复杂度是 O(logn)，而链表是 O(n)。因而，JDK1.8 对数据结构做了进一步的优化，引入了红黑树，链表和红黑树在达到肯定条件会进行转换：
- 当链表超过 8 且数组长度 (数据总量) 超过 64 才会转为红黑树
- 将链表转换成红黑树前会判断，如果以后数组的长度小于 64，那么会抉择先进行数组扩容，而不是转换为红黑树，以缩小搜寻工夫。
2. 说一下 HashMap 的特点
- hashmap 存取是无序的
- 键和值地位都能够是 null，然而键地位只能是一个 null
- 键地位是惟一的，底层的数据结构是控制键的
- jdk1.8 前数据结构是：链表 + 数组 jdk1.8 之后是：数组 + 链表 + 红黑树
- 阈值（边界值）>8 并且数组长度大于 64，才将链表转换成红黑树，变成红黑树的目标是进步搜寻速度，高效查问
3. 解决 hash 抵触的方法有哪些?HashMap 用的哪种？
解决 Hash 抵触办法有：凋谢定址法、再哈希法、链地址法（HashMap 中常见的拉链法）、简历公共溢出区。HashMap 中采纳的是链地址法。
- 凋谢定址法也称为再散列法，根本思维就是，如果 p =H(key)呈现抵触时，则以 p 为根底，再次 hash，p1=H(p)，如果 p1 再次出现抵触，则以 p1 为根底，以此类推，直到找到一个不抵触的哈希地址 pi。因而凋谢定址法所须要的 hash 表的长度要大于等于所须要寄存的元素，而且因为存在再次 hash，所以只能在删除的节点上做标记，而不能真正删除节点
- 再哈希法（双重散列，多重散列），提供多个不同的 hash 函数，R1=H1(key1)发生冲突时，再计算 R2=H2（key1），直到没有抵触为止。这样做尽管不易产生堆集，但减少了计算的工夫。
- 链地址法（拉链法），将哈希值雷同的元素形成一个同义词的单链表，并将单链表的头指针寄存在哈希表的第 i 个单元中，查找、插入和删除次要在同义词链表中进行，链表法实用于常常进行插入和删除的状况。
- 建设公共溢出区，将哈希表分为公共表和溢出表，当溢出产生时，将所有溢出数据对立放到溢出区
留神凋谢定址法和再哈希法的区别是
- 凋谢定址法只能应用同一种 hash 函数进行再次 hash，再哈希法能够调用多种不同的 hash 函数进行再次 hash
4. 为什么要在数组长度大于 64 之后，链表才会进化为红黑树
在数组比拟小时如果呈现红黑树结构，反而会升高效率，而红黑树须要进行左旋右旋，变色，这些操作来保持平衡，同时数组长度小于 64 时，搜寻工夫绝对要快些，总之是为了放慢搜寻速度，进步性能
JDK1.8 以前 HashMap 的实现是数组 + 链表，即便哈希函数获得再好，也很难达到元素百分百均匀分布。当 HashMap 中有大量的元素都寄存在同一个桶中时，这个桶下有一条长长的链表，此时 HashMap 就相当于单链表，如果单链表有 n 个元素，遍历的工夫复杂度就从 O（1）进化成 O（n），齐全失去了它的劣势，为了解决此种状况，JDK1.8 中引入了红黑树（查找的工夫复杂度为 O（logn））来优化这种问题
5. 为什么加载因子设置为 0.75，初始化临界值是 12？
HashMap 中的 threshold 是 HashMap 所能包容键值对的最大值。计算公式为 length*LoadFactory。也就是说，在数组定义好长度之后，负载因子越大，所能包容的键值对个数也越大
loadFactory 越趋近于 1，那么数组中寄存的数据（entry 也就越来越多），数据也就越密集，也就会有更多的链表长度处于更长的数值，咱们的查问效率就会越低，当咱们增加数据，产生 hash 抵触的概率也会更高
默认的 loadFactory 是 0.75，loadFactory 越小，越趋近于 0，数组中个寄存的数据 (entry) 也就越少，体现得更加稠密
0.75 是对空间和工夫效率的一种均衡抉择
如果负载因子小一些比方是 0.4，那么初始长度 16*0.4=6，数组占满 6 个空间就进行扩容，很多空间可能元素很少甚至没有元素，会造成大量的空间被节约
如果负载因子大一些比方是 0.9，这样会导致扩容之前查找元素的效率非常低
loadfactory 设置为 0.75 是通过多重计算测验失去的牢靠值，能够最大水平的缩小 rehash 的次数，防止过多的性能耗费
6. 哈希表底层采纳何种算法计算 hash 值？还有哪些算法能够计算出 hash 值？
hashCode 办法是 Object 中的办法，所有的类都能够对其进行应用，首先底层通过调用 hashCode 办法生成初始 hash 值 h1，而后将 h1 无符号右移 16 位失去 h2，之后将 h1 与 h2 进行按位异或（^）运算失去最终 hash 值 h3，之后将 h3 与 (length-1) 进行按位与（&）运算失去 hash 表索引
其余能够计算出 hash 值的算法有
- 平方取中法
- 取余数
- 伪随机数法
7. 当两个对象的 hashCode 相等时会怎么
hashCode 相等产生 hash 碰撞，hashCode 相等会调用 equals 办法比拟内容是否相等，内容如果相等则会进行笼罩，内容如果不等则会连贯到链表前方，链表长度超过 8 且数组长度超过 64，会转变成红黑树节点
8. 何时产生哈希碰撞和什么是哈希碰撞，如何解决哈希碰撞？
只有两个元素的 key 计算的 hash 码值雷同就会产生 hash 碰撞，jdk8 之前应用链表解决哈希碰撞，jdk8 之后应用链表 + 红黑树解决哈希碰撞
9. HashMap 的 put 办法流程
以 jdk8 为例，简要流程如下：
- 首先依据 key 的值计算 hash 值，找到该元素在数组中存储的下标
- 如果数组是空的，则调用 resize 进行初始化；
- 如果没有哈希抵触间接放在对应的数组下标里
- 如果抵触了，且 key 曾经存在，就笼罩掉 value
- 如果抵触后是链表构造，就判断该链表是否大于 8，如果大于 8 并且数组容量小于 64，就进行扩容；如果链表节点数量大于 8 并且数组的容量大于 64，则将这个构造转换成红黑树；否则，链表插入键值对，若 key 存在，就笼罩掉 value
- 如果抵触后，发现该节点是红黑树，就将这个节点挂在树上
10. HashMap 的扩容形式
HashMap 在容量超过负载因子所定义的容量之后，就会扩容。java 里的数组是无奈本人扩容的，将 HashMap 的大小扩充为原来数组的两倍
咱们来看 jdk1.8 扩容的源码
final Node<K,V>[] resize() {
//oldTab：援用扩容前的哈希表
Node<K,V>[] oldTab = table;
//oldCap：示意扩容前的 table 数组的长度
int oldCap = (oldTab == null) ? 0 : oldTab.length;
// 取得旧哈希表的扩容阈值
int oldThr = threshold;
//newCap: 扩容之后 table 数组大小
//newThr: 扩容之后下次触发扩容的条件
int newCap, newThr = 0;
// 条件成立阐明 hashMap 中的散列表曾经初始化过了，是一次失常扩容
if (oldCap > 0) {
// 判断旧的容量是否大于等于最大容量，如果是，则无奈扩容，并且设置扩容条件为 int 最大值，// 这种状况属于十分多数的状况
if (oldCap >= MAXIMUM_CAPACITY) {
threshold = Integer.MAX_VALUE;
return oldTab;
}// 设置 newCap 新容量为 oldCap 旧容量的二倍（<<1）, 并且 < 最大容量，而且 >=16，则新阈值等于旧阈值的两倍
else if ((newCap = oldCap << 1) < MAXIMUM_CAPACITY &&
oldCap >= DEFAULT_INITIAL_CAPACITY)
newThr = oldThr << 1; // double threshold
}
// 如果 oldCap= 0 并且边界值大于 0，阐明散列表是 null，但此时 oldThr>0
// 阐明此时 hashMap 的创立是通过指定的构造方法创立的, 新容量间接等于阈值
//1.new HashMap(intitCap,loadFactor)
//2.new HashMap(initCap)
//3.new HashMap(map)
else if (oldThr > 0) // initial capacity was placed in threshold
newCap = oldThr;
// 这种状况下 oldThr=0;oldCap=0，阐明没通过初始化，创立 hashMap
// 的时候是通过 new HashMap()的形式创立的
else { // zero initial threshold signifies using defaults
newCap = DEFAULT_INITIAL_CAPACITY;
newThr = (int)(DEFAULT_LOAD_FACTOR * DEFAULT_INITIAL_CAPACITY);
}
//newThr 为 0 时，通过 newCap 和 loadFactor 计算出一个 newThr
if (newThr == 0) {
// 容量 *0.75
float ft = (float)newCap * loadFactor;
newThr = (newCap < MAXIMUM_CAPACITY && ft < (float)MAXIMUM_CAPACITY ?
(int)ft : Integer.MAX_VALUE);
}
threshold = newThr;
@SuppressWarnings({"rawtypes","unchecked"})
// 依据下面计算出的后果创立一个更长更大的数组
Node<K,V>[] newTab = (Node<K,V>[])new Node[newCap];
// 将 table 指向新创建的数组
table = newTab;
// 本次扩容之前 table 不为 null
if (oldTab != null) {
// 对数组中的元素进行遍历
for (int j = 0; j < oldCap; ++j) {
// 设置 e 为以后 node 节点
Node<K,V> e;
// 以后桶位数据不为空，但不能晓得外面是单个元素，还是链表或红黑树，//e = oldTab[j]，先用 e 记录下以后元素
if ((e = oldTab[j]) != null) {
// 将老数组 j 桶地位为空，不便回收
oldTab[j] = null;
// 如果 e 节点不存在下一个节点，阐明 e 是单个元素，则间接搁置在新数组的桶位
if (e.next == null)
newTab[e.hash & (newCap - 1)] = e;
// 如果 e 是树节点，证实该节点处于红黑树中
else if (e instanceof TreeNode)
((TreeNode<K,V>)e).split(this, newTab, j, oldCap);
// e 为链表节点，则对链表进行遍历
else { // preserve order
// 低位链表：寄存在扩容之后的数组的下标地位，与以后数组下标地位统一
//loHead：低位链表头节点
//loTail 低位链表尾节点
Node<K,V> loHead = null, loTail = null;
// 高位链表，寄存扩容之后的数组的下标地位，= 原索引 + 扩容之前数组容量
//hiHead: 高位链表头节点
//hiTail: 高位链表尾节点
Node<K,V> hiHead = null, hiTail = null;
Node<K,V> next;
do {
next = e.next;
//oldCap 为 16:10000，与 e.hsah 做 & 运算能够失去高位为 1 还是 0
// 高位为 0，放在低位链表
if ((e.hash & oldCap) == 0) {if (loTail == null)
//loHead 指向 e
loHead = e;
else
loTail.next = e;
loTail = e;
}
// 高位为 1，放在高位链表
else {if (hiTail == null)
hiHead = e;
else
hiTail.next = e;
hiTail = e;
}
} while ((e = next) != null);
// 低位链表已成，将头节点 loHead 指向在原位
if (loTail != null) {
loTail.next = null;
newTab[j] = loHead;
}
// 高位链表已成，将头节点指向新索引
if (hiTail != null) {
hiTail.next = null;
newTab[j + oldCap] = hiHead;
}
}
}
}
}
return newTab;
}
扩容之后原地位的节点只有两种调整
- 放弃原地位不动（新 bit 位为 0 时）
- 散列原索引 + 扩容大小的地位去（新 bit 位为 1 时）
扩容之后元素的散列设置的十分奇妙，节俭了计算 hash 值的工夫，咱们来看一 下具体的实现
当数组长度从 16 到 32，其实只是多了一个 bit 位的运算，咱们只须要在意那个多进去的 bit 为是 0 还是 1，是 0 的话索引不变，是 1 的话索引变为以后索引值 + 扩容的长度，比方 5 变成 5 +16=21
这样的扩容形式不仅节俭了从新计算 hash 的工夫，而且保障了以后桶中的元素总数肯定小于等于原来桶中的元素数量，防止了更重大的 hash 抵触，平均的把之前抵触的节点扩散到新的桶中去
11. 个别用什么作为 HashMap 的 key？
个别用 Integer、String 这种不可变类当 HashMap 当 key
- 因为 String 是不可变的，当创立字符串时，它的 hashcode 被缓存下来，不须要再次计算，绝对于其余对象更快
- 因为获取对象的时候要用到 equals()和 hashCode()办法，那么键对象正确的重写这两个办法是十分重要的，这些类很标准的重写了 hashCode()以及 equals()办法
12. 为什么 Map 桶中节点个数超过 8 才转为红黑树？
8 作为阈值作为 HashMap 的成员变量，在源码的正文中并没有阐明阈值为什么是 8
在 HashMap 中有这样一段正文阐明，咱们持续看
* Because TreeNodes are about twice the size of regular nodes, we
* use them only when bins contain enough nodes to warrant use
* (see TREEIFY_THRESHOLD). And when they become too small (due to
* removal or resizing) they are converted back to plain bins. In
* usages with well-distributed user hashCodes, tree bins are
* rarely used. Ideally, under random hashCodes, the frequency of
* nodes in bins follows a Poisson distribution
* (http://en.wikipedia.org/wiki/Poisson_distribution) with a
* parameter of about 0.5 on average for the default resizing
* threshold of 0.75, although with a large variance because of
* resizing granularity. Ignoring variance, the expected
* occurrences of list size k are (exp(-0.5) * pow(0.5, k) /
* factorial(k)).
翻译
因为树节点的大小大概是一般节点的两倍，所以咱们只在箱子蕴含足够的节点时才应用树节点（参见 TREEIFY_THRESHOLD）。当他们边的太小（因为删除或调整大小）时，就会被转换回一般的桶，在应用散布良好的 hashcode 时，很少应用树箱。现实状况下，在随机哈希码下，箱子中节点的频率遵从泊松散布
第一个值是：* 0: 0.60653066
* 1: 0.30326533
* 2: 0.07581633
* 3: 0.01263606
* 4: 0.00157952
* 5: 0.00015795
* 6: 0.00001316
* 7: 0.00000094
* 8: 0.00000006
* more: less than 1 in ten million
树节点占用空间是一般 Node 的两倍，如果链表节点不够多却转换成红黑树，无疑会消耗大量的空间资源，并且在随机 hash 算法下的所有 bin 节点散布频率听从泊松散布，链表长度达到 8 的概率只有 0.00000006，简直是不可能事件，所以 8 的计算是通过重重迷信考量的
- 从均匀查找长度来看，红黑树的均匀查找长度是 logn，如果长度为 8，则 logn=3，而链表的均匀查找长度为 n /4，长度为 8 时，n/2=4，所以阈值 8 能大大提高搜寻速度
- 当长度为 6 时红黑树进化为链表是因为 logn=log6 约等于 2.6，而 n /2=6/2=3，两者相差不大，而红黑树节点占用更多的内存空间，所以此时转换最为敌对
13. HashMap 为什么线程不平安？
- 多线程下扩容死循环。JDK1.7 中的 HashMap 应用头插法插入元素，在多线程的环境下，扩容的时候有可能导致环形链表的呈现，造成死循环。因而 JDK1.8 应用尾插法插入元素，在扩容时会放弃链表元素本来的程序，不会呈现环形链表的问题
- 多线程的 put 可能导致元素的失落。多线程同时执行 put 操作，如果计算出来的索引地位是雷同的，那会造成前一个 key 被后一个 key 笼罩，从而导致元素的失落。此问题在 JDK1.7 和 JDK1.8 中都存在
- put 和 get 并发时，可能导致 get 为 null。线程 1 执行 put 时，因为元素个数超出 threshold 而导致 rehash，线程 2 此时执行 get，有可能导致这个问题，此问题在 JDK1.7 和 JDK1.8 中都存在
14. 计算 hash 值时为什么要让低 16bit 和高 16bit 进行异或解决
- 咱们计算索引须要将 hashCode 值与 length- 1 进行按位与运算，如果数组长度很小，比方 16，这样的值和 hashCode 做异或实际上只有 hashCode 值的后 4 位在进行运算，hash 值是一个随机值，而如果产生的 hashCode 值高位变化很大，而低位变动很小，那么有很大概率造成哈希抵触，所以咱们为了使元素更好的散列，将 hash 值的高位也利用起来 \
举个例子
如果咱们不对 hashCode 进行按位异或，间接将 hash 和 length- 1 进行按位与运算就有可能呈现以下的状况
如果下一次生成的 hashCode 值高位起伏很大，而低位简直没有变动时，高位无奈参加运算
能够看到，两次计算出的 hash 相等，产生了 hash 抵触
所以无符号右移 16 位的目标是使高凌乱度地区与地凌乱度地区做一个中和，进步低位的随机性，缩小哈希抵触
文章中呈现的对于面试题的谬误请在评论区指出，我再进行改过优化。如果文章对你有所帮忙，请给团长一个收费的赞吧，感激大家。
