Java Foundation---HashMap, HashTable

HashMap, Hashtable difference.

1, HashMap thread is unsafe, hashtable thread safety;

2, HashMap the keys and values are allowed to exist null values, and Hashtable not allowed;

3, HashMap efficiency is higher than Hashtable

* Hash table based implementation of the <tt>Map</tt> interface. This

* Implementation provides all of the optional map operations, and permits

* <tt>null</tt> values and the <tt>null</tt> key. (The <tt>HashMap</tt>

* Class is roughly equivalent to <tt>hashtable</tt>, except. It is

* unsynchronized and permits nulls.) This class makes no guarantees as to

* The order of the map; In particular, it does isn't guarantee that the order

* would remain constant over time.

HashMap is a structure store of a hash table (an array of linked lists). The bottom of the HashMap is primarily based on arrays and linked lists, which determine the location of the store (the subscript of the array) by calculating the hash, and each element of the array is the head node of a single-linked list. HashMap through the key hashcode to calculate the hash value, the hash value of the same object in the array position, there is a hash conflict, hashmap through the list of ways to solve.

When using objects as keys for HashMap and Hashtable, you need to implement the object's Hashcode () method and the Equals () method.

2 key factors that determine the performance of a hashmap:

Initial capacity (Initialize capacity, default 16) and load factor (load factor, the level of filling, default is 0.75). The initialization capacity must be 2 of the n-th party. The larger the load factor, the more elements filled up, the higher the space utilization, the greater the chance of the hash conflict, the longer the list length, the lower the search efficiency; the smaller the load factor, the less elements fill up, the more data will be evacuated, the space will be wasted (many spaces may need to be expanded), but hash collisions will be reduced

HashMap formula for calculating hash (array subscript): (table.length-1) & Hash

Hashtable formula for calculating hashes: (hash & 0x7FFFFFFF)% Tab.length (Division hash method)

In comparison, the modulus will use division efficiency is low, hashmap than hashtable efficiency of a little performance. Because the HashMap calculation is used (TABLE.LENGTH-1) & hash. If length is odd, then (table.length-1) is even, the last one (binary) is 0, so the hash value resulting from the & calculation is 0, that is, only an even number, so that any hash value will only be hashed to the array's even subscript position, This wastes half of the space, so the length takes 2 of the whole number of powers, that is, in order to make different hash values collision probability is small, also can avoid too much wasted space to make elements in the hash table evenly hash.

HashMap expansion: Newcap = oldcap << 1

When the number of elements exceeds the size of the array *load factor, the capacity is expanded by one-fold. That is, by default, when the number of HASHMAP elements exceeds 16*0.75=12, the array size expands to 2*16=32, and then the position of each element in the array needs to be recalculated (length changes cause the hash value to change), and the expansion is required to replicate the array. Copying an array is a very performance-intensive operation, so the number of preset elements can effectively improve HashMap performance when hashmap elements are predictable.

Hashtable expansion: int newcapacity = (oldcapacity << 1) + 1;

How to make HashMap sync: Map m = Collections.synchronizemap (HASHMAP);

Attention

Before JDK1.8: An element that uses a unidirectional list to store the same index value. In the worst case, this approach reduces the performance of the HashMap get method from O (1) to O (n).

In JDK1.8: In order to solve the problem of hashmap performance degradation during frequent collisions, use a balanced tree instead of the elements of the linked list storage conflict. This means that we can increase the worst-case performance from O (n) to O (Logn).

Use the constant treeify_threshold in Java 8 to control whether or not to switch to the balance tree for storage. Currently, this constant value is 8, which means that when the index of more than 8 elements is the same, HashMap uses the tree to store them.

This dynamic feature allows HashMap to start using a linked list and replace the linked list with a balanced binary tree when the number of conflicting elements exceeds a specified value. However, this feature is not in all hash table-based classes, such as Hashtable and Weakhashmap. Currently, only Concurrenthashmap,linkedhashmap and HashMap use the balance tree in frequent conflict situations.

In the expansion of the HashMap, do not need to re-calculate the hash like the implementation of JDK1.7, just to see the original hash value of the new bit is 1 or 0 is good, is 0 words index unchanged, is 1 words index into "original index +oldcap".

The time to recalculate the hash value is eliminated, and as the new 1bit is 0 or 1 it can be considered random, so the resize process evenly disperses the previously conflicting nodes into the new buckets. This piece is the JDK1.8 new optimization point. With a little attention to the difference, when the old linked list migrates the new linked list when the JDK1.7 is rehash, the list element is inverted if the array index in the new table is the same, but as you can see, the JDK1.8 is not inverted.

Java Foundation---HashMap, HashTable