equals&hashCode

经典规则:如果重写了equals,必须重写hashCode


为什么???

这个规则考虑的应用场景:如果你的对象可能放入HashMap,HashSet,不重写会出问题


问题场景:

new一个对象,重写了equals,但是没有重写hashCode,再new一个对象,原对象.equals(新对象)等于true时,但hashCode却不一致。

hashCode的默认计算规则:根据对象的内存地址进行映射,所以两个对象的内容相同,理论上来说是不能存入HashMap中的。

但如果hashCode不一致,HashMap就会把两个key相同的元素存到同一个集合中。


计算hash冲突时使用hashCode而不是equals:

hashCode效率更高


通过这个问题得到的反思:

之前一直有知道这个规则,但只是笼统的记住它,而不是理解。这个问题的关键突破点就是集合HashMap,但凡拿一个集合出来举例,理解起来就相当容易。

想起来之前通识课老师讲的一句话:物有本末,事有终始,知其先后,则近道矣。

posted @   笑谈渴饮匈奴血  阅读(145)  评论(0编辑  收藏  举报
编辑推荐:
· .NET Core 对象分配(Alloc)底层原理浅谈
· 聊一聊 C#异步 任务延续的三种底层玩法
· 敏捷开发:如何高效开每日站会
· 为什么 .NET8线程池 容易引发线程饥饿
· golang自带的死锁检测并非银弹
阅读排行:
· 聊一聊 C#异步 任务延续的三种底层玩法
· 上位机能不能替代PLC呢?
· 2024年终总结:5000 Star,10w 下载量,这是我交出的开源答卷
· .NET Core:架构、特性和优势详解
· 一个适用于 .NET 的开源整洁架构项目模板
点击右上角即可分享
微信分享提示