读源码-HashMap

致第的第一次(读源码):
突然发现,我不再年轻了,已经到了不得不改变了年纪,自己生命的宽度不够,深度也不够,再不非凡,就一直平庸。法国蒙田说过,灵魂没了目标,就会丧失自己。下了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啊。不过坚持>激情,坚持为王!加油!

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
平台声明:文章内容(如有图片或视频亦包括在内)由作者上传并发布,文章内容仅代表作者本人观点,简书系信息发布平台,仅提供信息存储服务。

推荐阅读更多精彩内容