Java容器之HashMap源码解析（视频讲解）

内容简介：讲解HashMap的底层数据结果、处理逻辑和源码实现。首先通过画图模拟HashMap的数据结果和底层处理逻辑；然后解析put和get方法，印证模拟中的原理；通过解读源码，讲解单向链表转换成红黑树的条件，以及何时又从红黑树转换回单向链表；最后分析initialCapacity和loadFactor在HashMap中的作用，以及他们对性能的影响。

视频地址：https://mp.weixin.qq.com/s/8z4jdDkDcwlTQi13UNsQCQ

内容补充：（由于视频时长的原因，下面做几点补充）

• 默认的初始capacity是2的4次方，即16。

• 如果设置的初始capacity不是2的n次方，底层会使用tableSizeFor方法将其设置为大于设置值的第一个2的n次方值。比如设置的初始capacity为10，实际上会使用16作为最终的初始capacity（为什么必须是2的n次方视频中有解释）。初始capacity会影响resize()的频率，因此如果要调优，应结合map中初始的条目数量和每次增加的数量总和考虑。但不应设置的过大，这个原因视频中有讲到。

• 我在视频中说了一个“重hash”的概念，我对其的定义是在原有的hashCode上再进行一次hash处理。如果大家看一些国外的文章，可能会看到“rehashing”的概念，这个概念指的是在resize()的时候，对原有的数据进行数组下标的重新分配。这两个概念是不同的。

• 这里重点强调一下，网上很多帖子说当列表长度大于8时（包含数组上的那个元素，总共是8个），链表就会转换成红黑树，这种说法不完整，为什么不完整，请注意视频中的相关讲解。

• 为什么长度大于8就有可能转红黑树。转红黑树的目的是为了优化查找速度，但红黑树的空间占用比链表大，因此这是一个空间和时间的权衡。为什么是8，这个原因在源码的一段注释中进行了解释。在给定时间或空间的前提下，不同key计算出相同数组下标的概率符合“泊松分布”，注释中给出一个得算，当loadFactor为0.75，且条目数大约占总容量的0.5倍时，对一个index而言，有0个key落在上面的可能性是0.6左右，1个的可能性是0.3左右，8个的时候为0.00000006，超过8个的概率就已经小于千万分之一了。因此当阈值为8时，除非你的HashMap存了大量的条目（个人估算至少百万级），出现红黑树的概率是很低的。这样就在时间和空间上取得一个比较好的权衡。

更多视频讲解请关注我的公众号：