understanding the relation between hashcode and equals method in Java [duplicate]

-1

This question already has an answer here:

This is my understanding about hashcode and equals method :

  • if obj1.hashcode == obj2.hashcode (returns true) then obj1.equals(obj2) returns true and
  • if obj1.equals(obj2) returns false (returns true) then obj1.hashcode == obj2.hashcode (returns false)

is this correct?

user1079065

출처 java equals hashcode
  • Wait a minute. How is this a duplicate? - Makoto
  • @Makoto, the linked Q&A explains the contract between the two exactly. So I don't know how this is not a duplicate. The answer to the OP's question is there. But hey, feel free to vote to reopen this question. - Bart Kiers
  • Well...from what I read of this question and the (formerly) linked duplicate, one is talking about pitfalls when implementing equals/hashCode, and this one is talking about an understanding of equals/hashCode. I don't see how the question is duplicated there. - Makoto
  • @Makoto the first and accepted answer identifies why a.equals(b) is true that a.hashCode() == b.hashCode(). Reading that answer should allow one to answer the 'is this correct?' question for one's self. If you continue to read (down in the depths of the answers), the one by Khaled specifically addresses the logical statement that is answered in this question. - user289086
  • @owlstead No problem. In the "as as long as the dup isn't deleted" - something that useful to do for 10k+ (can can see the deleted targets) is to go through this query and flag questions that have been deleted and are targets of a deleted post to be undeleted (and possibly historically locked), or retarget the dup, or delete them too. - user289086

3 답변

1

The convention between equals() and hashCode() mandates this:

  • If an object is determined to be equal, then their hash code must* be equal. That is to say, if obj1.equals(obj2), then obj1.hashCode() == obj2.hashCode().

  • If an object is determined to not be equal, then there is no hard-and-fast rule for what their hash code should be between them. They could return the same hash code, but this may cause a multitude of errors.

*: This "must" is actually unenforceable at compile time or run time, so take it with a grain of salt. Just note that you jeopardize the correctness of your application with equals/hashCode usage if it is not implemented correctly.

  • Could you reword the 'convention' to 'contract'? Its more than a convention which typically covers file structure, indents, comments, naming (getX/setX is a convention). The equals and hashCode relationship is more of a contract - it must work this way for things to work. I'll point out that "contract" is specifically used on the second line of the description - "The general contract of hashCode is:" - user289086
1

if obj1.hashcode == obj2.hashcode (returns true) then obj1.equals(obj2) might return true

From the javadoc

  • If two objects are equal according to the equals(Object) method, then calling the hashCode method on each of the two objects must produce the same integer result.
  • It is not required that if two objects are unequal according to the equals(java.lang.Object) method, then calling the hashCode method on each of the two objects must produce distinct integer results. However, the programmer should be aware that producing distinct integer results for unequal objects may improve the performance of hash tables

  • yes, I thought that second statement you had in there for a moment was wrong... - Alnitak
1

That is incorrect. The documentation for Object.equals(Object) has a formal explanation of the contract for extending this method. Essentially the intent for the Object.equals method is to check if two objects are actually the same object. However it often makes sense to override this functionality and instead make your class' equals method determine whether two objects are logically equal to each other (for example, two different instances of String objects which both represent the same sentence).

On the other hand, Object.hashCode() specifies the following contract:

The general contract of hashCode is:

  • Whenever it is invoked on the same object more than once during an execution of a Java application, the hashCode method must consistently return the same integer, provided no information used in equals comparisons on the object is modified. This integer need not remain consistent from one execution of an application to another execution of the same application.
  • If two objects are equal according to the equals(Object) method, then calling the hashCode method on each of the two objects must produce the same integer result.
  • It is not required that if two objects are unequal according to the equals(java.lang.Object) method, then calling the hashCode method on each of the two objects must produce distinct integer results. However, the programmer should be aware that producing distinct integer results for unequal objects may improve the performance of hash tables.

As much as is reasonably practical, the hashCode method defined by class Object does return distinct integers for distinct objects. (This is typically implemented by converting the internal address of the object into an integer, but this implementation technique is not required by the Java™ programming language.)

Basically, two different objects (either logically different or technically distinct) may have the same hashcode, because of how hashcodes are designed, but they should not be "equals". However, if two objects are equal to each other, they must have the same hashcode. Similarly, an object's hashcode may only change if the object itself changes in some way.

For further reading, see the Wikipedia article on hash functions.

Linked

Related

Latest