Three things you need to know about hashCode ().

Three things you need to know about hashCode ().

(Click the public account at the top of the page to follow it quickly)

 

Original article: eclipsesource
Translation: ImportNew-Southern Hemisphere
Link: http://www.importnew.com/16517.html

 

In Java, every object has a hashCode method that is easy to understand but sometimes forgotten or misused. There are three things to keep in mind to avoid common traps.

 

The hash code of an object allows algorithms and data structures to place the object into a compartment, just like letters in a printer case. The printer puts all the "A" types in A room. It only needs to search for the "A" type in this room. This simple system allows him to search for types in unordered drawers faster. This is also the idea of a hash-based set, such as HashMap and HashSet.

 

HashCode contract

 

This contract is described in JavaDoc of the hashCode method. It can be roughly summarized into the following points:

 

1. In a running process, equal objects must have the same hash code.

2. Note that this does not mean the following common misunderstandings:

3. Unequal objects must have different hash codes-error!

4. Objects with the same hash value must be equal -- error!

 

Hash code conflict

 

At any time, two different objects have the same hash code, which is called a conflict. Conflict does not matter, it only means that multiple objects are in the same space, so HashMap will check again to find the correct object. A large number of conflicts will reduce the system performance, but they will not lead to incorrect results.

 

However, if you mistakenly think that the hash code is the unique handle of an object, for example, using it as the Map key, you sometimes get the wrong object. Although conflicts are rare, they are inevitable. For example, the characters "Aa" and "BB" generate the same hash code: 2112. Therefore:

 

2. Never misuse a hash code as a key

 

You may disagree. Unlike the printer type example, in Java, there is 4,294,967,296 space (2 ^ 32 possible integer values ). It seems impossible for a 4 billion slot to conflict?

 

Variable hash code

 

Finally, in the hash code contract, there is a very important detail that is quite surprising: hashCode does not necessarily get the same result in different application executions. Let's take a look at the Java documentation:

 

During a Java application execution, the hashCode method must always return the same integer for the same object, but this integer does not reflect whether the object is modified (equals comparison. For different executions of the same application, this integer does not have to be consistent.

 

In fact, this is uncommon. classes in some class libraries even specify the exact formulas (such as strings) they are used to calculate hash codes ). For these classes, the hash code will always be the same. Although the implementation of most Hash Codes provides stable values, you cannot rely on this. As pointed out in this article, some class libraries return different hash values in different processes, which may be confusing. Google's Protocol Buffers is an example.

 

Therefore, you should not use Hash Codes in distributed applications. A remote object may have different hash codes than a local object, even if the two objects are equal.

 

3. Do not use Hash Codes in distributed applications

 

In addition, you should be aware that the implementation of the hash code function from one version to another may be changed. Therefore, your code should not depend on any specific hash code value. For example, you should not use a hash code for persistence. The next time you run the program, the hash code of the "same" object may be different.

The best suggestion is: Do not use hash code unless you have created a hash-based algorithm.

 

SHA1

 

You may know that the encrypted hash code SHA1 is sometimes used to identify objects (such as git ). Is this insecure? No. SHA1 uses a 160-bit key, which makes the conflict almost impossible. Even if there are many objects, the chance of conflict in this space is much lower than the chance that a meteor hits the computer where you are executing the program. This article provides a good overview of the probability of conflict.