致第的第一次(读源码)：
突然发现，我不再年轻了，已经到了不得不改变了年纪，自己生命的宽度不够，深度也不够，再不非凡，就一直平庸。法国蒙田说过，灵魂没了目标，就会丧失自己。下了5年，改变自己，跳出自己的舒适区。在人生的赛道上，和自己比赛，超越原来的自己，成为另一个自己的巅峰。

1.数据结构

HashMap数据结构图

HashMap的底层结构：数组+链接。

核心元素结构： 核心元素结构

2.put操作

put主逻辑

1.如果数组是空，则填充。
2.如果key是null，存储空的key。
3.计算key对应的tableIndex。
4.如果已经存在相同的key(一样的hash值并且key相等<==或equal>)，则用新的value覆盖原来的value，并返回原来的value。
5.将新的Entry添加到当前的链表中(插入到头结点后)。

3.关键代码

1.为什么table的size必须是2的次幂？

 如上图所示：需要存入<k1,v1>,<k2,v2>.
 hash<k1>=1001
 hash<k2>=1000
               
 计算tableIndex的代码：
 static int indexFor(int  hash, int length) {        
    return hash & (length-1);
 }

如果tableSize=15,那么两个key对应的hash，hash & (length-1)执行的结果是一样的，所以两个key就会存到同一个bucket里，这就出现key的冲突。

如果tableSize=16,那么两个key对应的hash，hash & (length-1)执行的结果是不同的，避免了key冲突。

如果冲突严重，那么大部分的Entry就会落在同一个bucket中，那么在执行get操作的时候，遍历链表就会耗时。

4.get操作

5.resize

当hashmap中的元素越来越多的时候，碰撞的几率也就越来越高（因为数组的长度是固定的），所以为了提高查询的效率，就要对hashmap的数组进行扩容，在hashmap数组扩容之后，最消耗性能的点就出现了：原数组中的数据必须重新计算其在新数组中的位置，并放进去，这就是resize。

HashMap扩容的场景：元素个数 > 数组大小*loadFactor。

尽量避免HashMap的resize，因为这个操作比较耗时。那么在初始化HashMap的时候，如果避免执行resize，同时又满足“&”的要求呢？

举个栗子：

有1000个元素new HashMap(1000), 但是理论上来讲new HashMap(1024)更合适，更何况，hashmap也自动会将其设置为1024。 但是new HashMap(1024)还不是更合适的，因为0.75*1024 < 1000, 也就是说为了让0.75 * size > 1000, 我们必须这样new HashMap(2048)才最合适，既考虑了&的问题，也避免了resize的问题。

6.为什么自定义的key，必须重写hashcode和equals方法呢？

比如说自定义了一个User，以User作为key，存入HashMap。

定义
User u1 = new User(1,"dcx");
User u2 = new User(1,"dcx");

虽然u1和u2具有共同的属性，但是u1和u2的hashcode是不一样的(如果不重写，hashcode默认是对象的内存地址)。

hashcode不一样，tableIndex = hashcode & (tableLength - 1)也不一样。这样在get的时候，永远也获取不到了。

如果重写了hashcode，但是没有重写equals方法，那么tableIndex一样，但是在遍历的时候，是需要equals来做判断的。因此必须重写equals方法。

---

第一次写文章，好LOW啊。不过坚持>激情，坚持为王！加油！