equals&hashCode
经典规则:如果重写了equals,必须重写hashCode
为什么???
这个规则考虑的应用场景:如果你的对象可能放入HashMap,HashSet,不重写会出问题
问题场景:
new一个对象,重写了equals,但是没有重写hashCode,再new一个对象,原对象.equals(新对象)等于true时,但hashCode却不一致。
hashCode的默认计算规则:根据对象的内存地址进行映射,所以两个对象的内容相同,理论上来说是不能存入HashMap中的。
但如果hashCode不一致,HashMap就会把两个key相同的元素存到同一个集合中。
计算hash冲突时使用hashCode而不是equals:
hashCode效率更高
通过这个问题得到的反思:
之前一直有知道这个规则,但只是笼统的记住它,而不是理解。这个问题的关键突破点就是集合HashMap,但凡拿一个集合出来举例,理解起来就相当容易。
想起来之前通识课老师讲的一句话:物有本末,事有终始,知其先后,则近道矣。
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】博客园携手 AI 驱动开发工具商 Chat2DB 推出联合终身会员
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· .NET Core 对象分配(Alloc)底层原理浅谈
· 聊一聊 C#异步 任务延续的三种底层玩法
· 敏捷开发:如何高效开每日站会
· 为什么 .NET8线程池 容易引发线程饥饿
· golang自带的死锁检测并非银弹
· 聊一聊 C#异步 任务延续的三种底层玩法
· 上位机能不能替代PLC呢?
· 2024年终总结:5000 Star,10w 下载量,这是我交出的开源答卷
· .NET Core:架构、特性和优势详解
· 一个适用于 .NET 的开源整洁架构项目模板