天下无难试之HashMap面试刁难大全

HashMap的结构无疑是Java面试中出现频率最高的一道题，这个题是如此之常见，应该每个人都会信手拈来。可是就在我经历过的无数【允许我夸张一下】面试当中，能完整回答我提出的HashMap问题的人却是寥寥无几，如今这道题我已经问的有点厌烦了。

HashMap的结构是怎样的？

二维结构，第一维是数组，第二维是链表

Get方法的流程是怎样的？

先调用Key的hashcode方法拿到对象的hash值，然后用hash值对第一维数组的长度进行取模，得到数组的下标。这个数组下标所在的元素就是第二维链表的表头。然后遍历这个链表，使用Key的equals同链表元素进行比较，匹配成功即返回链表元素里存放的值。

Get方法的时间复杂度是多少？

小伙伴们在回答这道题是有很多人会开始怀疑人生，他们的脑细胞这个时候会出现短路现象。明明是O(1)啊，平时都记得牢牢的，可是刚才Get方法的流程里需要遍历链表，遍历的时间复杂度难道不是O(n)么？此刻观察这些孩子们的表情是非常卡哇伊呢的。当然还有些甚至是科班的小伙伴居然没听过时间复杂度，想到这里我也开始怀疑人生了。当他们卡壳的时候，我会稍微提醒一下，问下面的这一道题。

假如HashMap里的元素有100w个，请问第二维链表的长度大概是多少？

嗦嘎！链表的长度很短，相比总元素的个数可以忽略不计。这个时候小伙伴们的眼睛通常会开始发光，很童贞。作为面试官是很喜欢看到这种眼神的。我使用反射统计过HashMap里面链表的长度，在HashMap里放了100w个随机字符串键值对，发现链表的长度几乎从来没有超过7这个数字，当我增大loadFactor的时候，才会偶尔冒出几个长度为8的链表来。于是问题又来了。

既然链表如此短，为啥Java8要对HashMap的链表进行改造，使用红黑树来代替链表呢？

有很多同学都没具体去深入关注Java8的新特性，如果他们回答不上来，我也不会感到失望。因为到这个问题的时候，已经只剩下15%的同学不到了，如果再打击他们，看着他们落寞的身影走出了大门，我都要对自己感到失望了，怎么招个人就如此困难？

这道题的关键在于如果Key的hashcode不是随机的，而是人为特殊构造的话，那么第二维链表可能会无比的长，而且分布极为不均匀，这个时候就会出现性能问题。比如我们把对象的hashcode都统一返回一个常量，最终的结果就是hashmap会退化为一维链表，Get方法的性能巨降为O(n)，使用红黑树可以将性能提升到O(log(n))。

请解释一下HashMap的参数loadFactor，它的作用是什么？

loadFactor表示HashMap的拥挤程度，影响hash操作到同一个数组位置的概率。默认loadFactor等于0.75，当HashMap里面容纳的元素已经达到HashMap数组长度的75%时，表示HashMap太挤了，需要扩容，在HashMap的构造器中可以定制loadFactor。

请说明一下HashMap扩容的过程

扩容需要重新分配一个新数组，新数组是老数组的2倍长，然后遍历整个老结构，把所有的元素挨个重新hash分配到新结构中去。这个rehash的过程是很耗时的，特别是HashMap很大的时候，会导致程序卡顿，而2倍内存的关系还会导致内存瞬间溢出，实际上是3倍内存，因为老结构的内存在rehash结束之前还不能立即回收。那为什么不能在HashMap比较大的时候扩容扩少一点呢，关于这个问题我也没有非常满意的答案，我只知道hash的取模操作使用的是按位操作，按位操作需要限制数组的长度必须是2的指数。另外就是Java堆内存底层用的是tcmalloc这类library，它们在内存管理的分配单位就是以2的指数的单位，2倍内存的递增有助于减少内存碎片，减少内存管理的负担。

HashMap是线程安全的么？

当然不是，线程安全的HashMap是ConcurrentHashMap。关于ConcurrentHashMap还可以问很多问题，这就需要另一篇文章来具体讲解了。

你了解Redis么，你知道Redis里面的字典是如何扩容的么？

好，如果这道题你也回答正确了，恭喜你，毫无无疑，你是一位很有钱途的高级程序员。

你了解Python么，你知道Python里面字典的结构是怎样的么？

这个就属于附加题了，如果这道题你也回答对了，那我的眼睛就要发射紫外线了。