其实就想分享两篇博客，希望看官能多看这两篇博客。能够看懂的话，应对面试是绝对没有问题的。
来自美团一堆文章里的一篇。
https://tech.meituan.com/java-hashmap.html
这篇也不错，从最细节的地方说明了每个字段具有怎样的意义，以及每个字段为什么这么设计。总之很棒。
https://www.cnblogs.com/zhangyinhua/p/7698642.html
下面纯属虚构，不要认真。
遐想一下几个特性，
首先从事java开发的这帮人，觉得对一个接口只有一个方法。每次用到这个接口的话，还得写一个实现类，是不是有点麻烦了。就一个方法还得写实现吗？我们可以传递参数，难道我们就不可以传递代码块了。好了，我们都一致决定可以传递代码块。那么我们应该怎么定义呢，参考到大多数的业务场景，都有消费数据，生产数据，以及对数据做处理，对数据做判断。干脆我们定义几大这样的接口吧。每个接口写个方法。至于里面的业务实现，咱们不管。让程序员去传递业务代码块好了。函数式编程开始了（jdk1.8以前也有函数式编程，不要在意这些细节）。
然后代码块的书写应该怎么写呢，总得有个格式吧，参考js的匿名函数，胖箭头，以及C#的lambda表达式，我们就->来定义把。于是lambda表达式出世了。
然后呢lambda出来了，设计java底层的这帮人总得用上他们把，所以呢，集合成为了首选目标，因为总是得写循环啊，干脆现在循环里面写吧。所以很人性化的有了forEach方法，参数可以传递lambda表达式。这也是最最开始我接触lambda表达式的一个方法。
但是发现集合的子类挺多的，难道每个子类都增加一个forEach方法的实现吗？没有必要啊，他们的实现都一样啊。干嘛每个子类都加一遍呢？那好吧咱们在接口里面加上吧，可是接口里只能有方法的声明，不能有实现啊。大家都沉思了一会儿，然后相视一笑，接口的default方法和static方法出现了。
下面再介绍下学习HashMap源码的过程，站在巨人的肩膀上，看的更远。站在多个巨人的肩膀上，你就是聪明人了。就像射雕英雄传的郭靖，有那么多的师父，自然就成为一个神功盖世的大英雄了。所以多站在巨人的肩膀上。另外怎么才能站在巨人的肩膀上呢？看源码的过程中，遇到不会的就去查，查的多了，找到的巨人就多了，会的就多了。