Java8 source-hashtable (1) __hashtable

HashMap has learned the source code, today began to learn Hashtable. The reference JDK version is 1.8. PS: Previously did not notice that the T in Hashtable is lowercase ... )

I believe that we have some understanding of Hashtable, Hashtable and HashMap, from the storage structure and implementation is basically the same. The biggest difference between it and HashMap is that it is thread-safe, and it does not allow key and value to be null. Hashtable is an obsolete collection class that is not recommended for use in new code, where thread-safe situations can be replaced with HashMap, and Concurrenthashmap can be replaced with a thread-safe occasion. But that is not the reason why we do not understand it. At the very least Hashtable and HashMap interview questions are often asked in the interview. How Hashtable is implemented in thread-safe. The similarities and differences between Hashtable and HashMap. This paper will analyze the internal structure and realization principle of Hashtable to help us learn hashmap and Hashtable. Top Comment

This class implements a hash table, which the maps keys to values. Any Non-null object can be used as a key or as a value.

This class is the implementation of the hash table, the mapping set of key and value pair. Any non-null object can be used as a key or Vlaue.

To successfully store and retrieve objects from a Hashtable, the objects used as keys must implement the Hashcode method a nd the Equals method.

In order to successfully save and retrieve objects in a hash table, the object used as a key must implement the Hashcode method and the Equals method.

An instance of Hashtable has two parameters this affect its performance:initial capacity and load factor. The capacity is the number of buckets in the hash table, and the initial capacity are simply the capacity at the time the H The ash table is created. Note this hash table is open:in the case to a "hash collision", a single bucket stores multiple entries, which must b E searched sequentially. The load factor is a measure of how full the hash table is allowed to get before it capacity is automatically. The initial capacity and load factor parameters are merely to the hints. The exact details as to, and whether the rehash is invoked are implementation-dependent.

An instance of Hashtable has two parameters that affect its behavior: initializing capacity initial capacity and load factor load factor. Capacity is the number of buckets in the hash table, and the initialization capacity is the capacity of the hashtable when it is created. The hash table is open, and in the case of a hash collision, a bucket stores several node that must be sequentially searched. A load factor is a measure of how much a hash table can be full before it is automatically expanded (a hashtable is almost never expanded at full time, the larger the load factor, the more nodes the hash tables can hold before the expansion). Initialization capacity initial capacity and load factor load factor only have subtle hints of implementation. When to expand, whether the expansion depends on the specific implementation.

Generally, the default load factor (.) offers a good tradeoff between time and space costs. Higher values decrease the "space overhead but increase" time cost to look up a entry (which is reflected in most Hasht Able operations, including and put).

In general, the default load factor 0.75 is a good balance between hash tables and time and space costs. Higher load factors reduce space overhead but increase the time overhead of lookup operations (which affects most hash operations, including get and put operations).

The initial capacity controls a tradeoff between wasted space with need for rehash operations, which are . No rehash operations would ever occur if the initial capacity is greater than the maximum number of entries the Hashtable W Ill contain divided by its load factor. However, setting the initial capacity too high can waste space.

Initialize capacity initial capacity balance between space overhead and time overhead for expansion operations. If the initial capacity is larger than the number of node contained in the hash Table/load factor, the hash table will not be enlarged. However, the initial capacity set too tall to increase the space cost.

If Many entries are to is made into a Hashtable creating it with a sufficiently large capacity could allow the entries to B e inserted more efficiently than letting it perform automatic rehashing as needed to grow the table.

If you know ahead of time that Hashtable is going to store many node, creating a Hashtable initial capacity the appropriate setting will make the element more efficient, or the large capacity may lead to frequent expansion.

This example creates a hashtable of numbers. It uses the names of the numbers as keys:
Hashtable<string, integer> numbers= new hashtable<string, integer> ();
Numbers.put ("One", 1);
Numbers.put ("Two", 2);
Numbers.put ("three", 3);}
To retrieve a number and use the following code:
Integer n = numbers.get ("two");
if (n!= null) {
System.out.println ("two =" + N);
}}

This example demonstrates how to create Hashtable, store elements, and take out elements.

The iterators returned by the iterator method of the collections returned by all Is this class ' s "Collection View Methods" Are fail-fast:if the Hashtable is structurally modified to any time after the iterator was created, in any way except Ough The iterator ' s own Remove method, the iterator'll throw a concurrentmodificationexception. Thus, in the concurrent modification, iterator fails quickly and cleanly, rather than risking arbitrary, non-d Eterministic behavior at a undetermined time in the future. The enumerations returned by Hashtable's keys and elements methods are not fail-fast.

The iterator returned by the iterator method is fail-fast. If the Hashtable is modified structurally after the iterator is created, the iterator throws a Concurrentmodificationexception exception in addition to the iterator's own remove method. Therefore, faced with concurrent modifications, iterators are crisp and fail rather than adventurous to continue. The key and element collections of a hash table return enumerations is not fail-fast.

Note that the fail-fast behavior of a iterator cannot be guaranteed as it are, generally speaking, impossible to Hard guarantees in the presence of unsynchronized concurrent modification. Fail-fast iterators throw concurrentmodificationexception on a best-effort basis. Therefore, it would be wrong to write a program that depended on this exception for its correctness:the fail-fast R of Iterators should be used to detect bugs.

The fail-fast mechanism of iterators is not guaranteed, and it does not guarantee that this error will occur. In general, Fail-fast will do its best to throw concurrentmodificationexception exceptions. Therefore, it is wrong to write a program that relies on this exception to improve the correctness of such operations: Concurrentmodificationexception should only be used to detect bugs.

As of the Java 2 platform v1.2, this class is retrofitted to implement the Map interface, making it a member of the Colle Ction.

Since JAVA2 began, Hashtable inherited the map interface and became a member of the container.

Java Collections Framework. Unlike the new collection implementations, Hashtable is synchronized. If a Thread-safe implementation is isn't needed, it is recommended to use HASHMAP in place of Hashtable. If a thread-safe highly-concurrent implementation is desired, then it are recommended to use Java.util.concurrent.Concurren Thashmap in place of Hashtable.

Unlike the new set implementations, Hashtable is thread-safe. If a thread-safe implementation is not required, it is recommended that you use HashMap instead of Hashtable. If you need a thread-safe implementation, it is recommended that you use JAVA.UTIL.CONCURRENT.CONCURRENTHASHMAP instead of Hashtable.

@author Arthur van Hoff
@author Josh Bloch
@author Neal Gafter
@see Object#equals (Java.lang.Object)
@see Object#hashcode ()
@see Hashtable#rehash ()
@see Collection
@see Map
@see HashMap
@see TreeMap
@since JDK1.0

After reading the above content, we should be able to feel that Hashtable indeed and hashmap very similar.

The next article will continue to explain Hashtable.

This article has been included in the JAVA8 container source code notes column.