当在Java中重写equals方法时，通常也需要重写hashCode方法，以保持两个相等对象的hashCode一致性。不这样做可能会导致问题，特别是在使用依赖hashCode的集合如HashMap中。如果两个对象equals相等但hashCode不同，会导致集合行为异常。不违反此约定，在某些特定场景下可能不会立即出现问题，但在多线程或复杂数据结构中可能会遇到不可预测的结果。
I read in many places saying while override equals method in Java, should override hashCode method too, otherwise it is "violating the contract".
But so far I haven't faced any problem if I override only equals method, but not hashCode method.
What is the contract? And why am I not facing any problem when I am violating the contract? In which case will I face a problem if I haven't overridden the hashCode method?
解决方案
The problem you will have is with collections where unicity of elements is calculated according to both .equals() and .hashCode(), for instance keys in a HashMap.
As its name implies, it relies on hash tables, and hash buckets are a function of the object's .hashCode().
If you have two objects which are .equals(), but have different hash codes, you lose!
The part of the contract here which is important is: objects which are .equals() MUST have the same .hashCode().
This is all documented in the javadoc for Object. And Joshua Bloch says you must do it in
扫一扫
431
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
