Rewriting and rewriting the equals method hashcode methods do not necessarily causation

See a lot of the blog title is set to " Why after rewriting the equals method must override the hashcode method ", although this is a face questions, in fact, if not look at the situation to generalize the proposition, it is likely to cause unnecessary misunderstandings. The above title easily formed causality between equals and hashCode, equals because, hashCode is fruit. However, read the source should know, equals method of Object default is to return this == otherObj, and hashCode method is a local native, is implemented by the underlying c ++, is completely independent of the two methods, there is no causal relationship.

To discuss the relationship between the two can not be separated unordered collection will not be repeated , such as HashSet, HashMap and the like, a preferred example is the unordered collection will not be repeated access to the custom object :( with the Person custom object, there field name, age, etc., is assumed business name and age requirements are considered equal two equal the Person : )

First, almost ready for the next Basics

  • HashMap and HashSet such as how the data stored? Simply speaking in two steps, the first step, it is worth to the logical address of the hash object person A. The second step, if no other objects on the address A, then into success, otherwise the list (jdk1.7) or red-black tree (jdk1.8) treatment hash collision, how to deal with? A starting point to find one traversal of the list A hanging or hanging on the binary search tree A red-black, red-black tree, or if the linked list node are not equal to each person (Comparative equals call), put the person hanging up, that is, put the success, or find an equal node updates its value with the person

HashSet want to deposit such a Person, it must first know where to put this Person, Person then calls the hashCode method returns a hash value, and, and length - 1 phase generates its logical address, as FIG. If you're lucky, did not address the conflict, HashSet to determine the Person up here

  • Like Integer, String, Byte, Boolean and other objects, java has been rewritten corresponding hashCode methods, making a hash value different values ​​of the same heap object is still the same, the custom object is called Object hashCode method, which is c ++ realize native methods, as long as the heap object is different hash values ​​are not the same

Once you understand the basics difficult to find,

The reason to override the hashCode is to ensure that the hash value of a plurality of equal Person heap objects are equal

If not rewrite hashCode , Person native method call is c ++ to achieve, even if you are out of the two new Person object name and age are the same, but because it is two different heap objects, the set of c ++ code that will hash out different the result, so the logical address is different, HashMap see a different logical address will be kept to two different places, so one of the two different Person HashMap appeared first, and red business conflict, the second, and unordered collection of unique definition of conflict, third, you get at the time of the operation, it does not know which one to get you

The reason for rewriting the equals , first, to business logic, namely custom objects to compare what is considered equal, after all, more than one field. Second, in order to ensure the same duplicate custom object does not appear in the HashSet or HashMap

If not rewrite equals , then the HashMap or HashSet in a red-black tree traversing the list or do not know how relatively Person objects considered the same as dealing with conflict can only be called Object equals method, using == compares reference address, name and age cause are equal Person will be judged not the same, the same conflict with the scarlet letter business. Furthermore, assuming you have the right to rewrite hashCode method , i.e., to ensure that the same name and age is the Person heap objects will hash to the same logical address A, this time is assumed to three identical the Person name and age, a second after a Person a is mapped to objects have been found, so try to resolve hash collision, call equals comparisons, by comparing discovered after == not equal, HashMap relieved, happy to be directly linked to the second Person a's a list or a red-black tree, so, HashMap appeared two same Person! ! So you find that after rewriting hashCode method must also override equals

Thus, rewrite and rewrite hashCode between equals method is not necessarily a causal relationship, it is green font, the title is not that they can be changed to "Why rewrite hashCode also must override equals?" It? HashMap internal logic of the relationship, and equals the hashCode itself a peer indispensable. A better question is asked should be: "Why when programming sometimes need to override hashCode and equals method?"

Published 37 original articles · won praise 42 · Views 140,000 +

Guess you like

Origin blog.csdn.net/qq_37960007/article/details/104216478