Java Theory and Practice: hashing

Each Java object has a hashcode () and Equals () method. Many classes ignore (Override) default implementations of these methods to provide deeper semantic comparability between object instances. In the Java Philosophy and Practice section, Java Developer Brian Goetz introduces you to the rules and guidelines you should follow when creating Java classes to effectively and accurately define hashcode () and Equals (). You can discuss your views on this article with the author and other readers in the discussion forum. (You can also click on the discussion at the top or bottom of this article to enter the Forum.) )

Although the Java language does not directly support associative arrays--you can use any object as an array of indexes--the use of the Hashcode () method in the root object class makes it clear that you expect extensive use of hashmap (and its predecessor Hashtable). Ideally, a hash-based container provides effective insertion and efficient retrieval, and hashing directly in object mode facilitates the development and use of a hash-based container.

Define the equality of objects

The object class has two methods to infer the identity of the objects: Equals () and hashcode (). In general, if you ignore one of these, you must ignore both, as there is a vital relationship that must be maintained between the two. The special case is based on the Equals () method, and if two objects are equal, they must have the same hashcode () value (although this is not usually true).

The semantics of Equals () for a particular class are defined on the left side of the implementer, and the definition of equals () for a particular class means what is part of its design effort. The default implementation of object provides a simple reference to the following equation:

public boolean equals (Object obj) {return (this = = obj);}

In this default implementation scenario, the two references are equal only if they refer to the true same object. Similarly, the default implementation of the Hashcode () provided by object is generated by mapping the memory address of an object to an integer value. Since the address space is greater than the range of int values on some architectures, it is possible for two different objects to have the same hashcode (). If you ignore Hashcode (), you can still use the System.identityhashcode () method to access such defaults.

Ignore equals ()--simple instance

By default, Equals () and Hashcode () are based on identity enforcement, but for some classes they want to loosen the definition of the equation. For example, the integer class defines equals () similar to the following:

public boolean equals(Object obj) {
return (obj instanceof Integer
&& intvalue() == ((Integer) obj).intvalue());
}

In this definition, the two integer objects are equal only if they contain the same integer value. Binding will be an integer that cannot be modified, which makes it practical to use integer as the keyword in hashmap. This equal method can be used by all the original encapsulated classes in the Java class library, such as integers, Float, character, and Boolean and string (if two string objects contain the same sequence of characters, they are equal). Because these classes are not modifiable and can implement Hashcode () and Equals (), they can all be good hash keywords.

Why ignore Equals () and hashcode ()?

What if the integer does not ignore equals () and hashcode ()? If we never use integer as a keyword in hashmap or other hash-based collections, nothing happens. However, if we use such an integer object as a keyword in hashmap, we will not be able to reliably retrieve the associated value unless we use an integer instance that is extremely similar to the put () call in the Get () call. This requires ensuring that only one instance of an integer object corresponding to a particular integer value is used in our entire program. Needless to say, this method is extremely inconvenient and frequently wrong.

The interface contract of object requires that if the Equals () two objects are equal, they must have the same hashcode () value. Why do our root object classes need to be hashcode () when their recognition capabilities are all contained in Equals ()? The Hashcode () method is simply used to improve efficiency. Java Platform designers anticipate the importance of hashing collection classes (Collection Class) In typical Java applications-such as Hashtable, HashMap, and hashset-and use Equals () with many Comparison of objects is very expensive in terms of calculation. Enables all Java objects to support Hashcode () and use a hash based collection to enable efficient storage and retrieval.

Requirements for implementing Equals () and Hashcode ()

There are some limitations to implementing equals () and Hashcode (), which are listed in the object file. In particular, the Equals () method must display the following properties:

Symmetry: Two references, A and b,a.equals (b) if and only if B.equals (a)

Reflexivity: All non-null references, A.equals (a)

Transitivity:if A.equals (b) and B.equals (c), then A.equals (c)

Consistency with hashcode (): Two equal objects must have the same hashcode () value

The specification of object does not explicitly require that equals () and hashcode () must be consistent-their results will be the same in subsequent calls, assuming "do not alter any information used in object equality comparisons." "It sounds like" the result of the calculation will not change unless it is actually the case. "This vague statement usually explains that equality and hash value calculations should be the deterministic function of an object, not the other."