HashMap conflict Resolution __java in Java 8

Before Java 8, HashMap and other map-based classes resolved conflicts through chain addresses, using one-way lists to store elements of the same indexed value. In the worst case scenario, this approach lowers the performance of the HashMap get method from O (1) to O (n). To address the problem of hashmap performance during frequent conflicts, the balance tree is used in Java 8 to replace the elements of a linked list storage conflict. This means that we can increase the worst-case performance from O (n) to O (Logn). The
uses constant treeify_threshold in Java 8 to control whether to switch to the balance tree for storage. Currently, this constant value is 8, which means that when there are more than 8 elements indexed, HashMap uses the tree to store them.
This change is to continue to optimize common classes. You may recall that in Java 7, in order to optimize common classes, the delayed loading mechanism for ArrayList and HashMap was used, and memory was not allocated before elements were added, which reduced the amount of memory occupied by empty lists and HashMap.
This dynamic feature allows HashMap to use a linked list at the outset and replace the list with a balanced binary tree when the number of conflicting elements exceeds the specified value. However, this feature is not in all the hash table based classes, such as Hashtable and Weakhashmap.
Currently, only Concurrenthashmap,linkedhashmap and HashMap use the balance tree in case of frequent conflict. When a conflict occurs

The Hashcode () method is called in HashMap to compute the hashcode.
Because two different objects in Java may have the same hashcode, different keys may have the same hashcode, resulting in conflicts. Summary HashMap uses a linked list to store elements of the same index when handling conflicts. Starting with Java 8, Hashmap,concurrenthashmap and Linkedhashmap use a balance tree to replace a linked list when dealing with frequent conflicts, and when the number of elements in the same hash bucket exceeds a specific value, the list switches to the balance tree, which moves the Get () The performance of the method is increased from O (n) to O (Logn). When you switch from a linked list to a balanced tree, the order of the HashMap iterations changes. This does not cause any problems, however, because HashMap does not provide any assurance about the order of iterations. The Hashtable class, which exists from Java 1, does not use a balanced tree to ensure that the iteration order remains unchanged, even in the case of frequent conflicts. The decision was made to not break some of the older Java applications that depended on the Hashtable iteration order. In addition to Hashtable, Weakhashmap and Identityhashmap do not use the balance tree in frequent conflict situations. Using HashMap causes a conflict because the Hashcode () method of the Key object is used, and the Equals () and Hashcode () methods do not guarantee that the hashcode of the different objects is different. It is important to remember that the hashcode of the same object must be the same, but the same hashcode is not necessarily the same object. In Hashtable and hashmap, conflicts occur because the Hashcode () method of different objects returns the same value.

The above is how HashMap handles conflicts in Java. This method is called the chain address method, because it uses a linked list to store elements within the same bucket. Usually the situation hashmap,hashset,linkedhashset,linkedhashmap,concurrenthashmap,hashtable, Both Identityhashmap and Weakhashmap use this approach to handle conflicts.

Starting with JDK 8, Hashmap,linkedhashmap and Concurrenthashmap use the balance tree to replace the linked list in order to improve performance and frequently conflict. Because HashSet internal use of the Hashmap,linkedhashset internal use of linkedhashmap, so their performance will also be improved.

The HashMap is fast and efficient, making it very widely used. The principle is that the hashcode () and Equals () methods are invoked, and the hashcode is given a certain hash operation to get the corresponding value position information and to be divided into different buckets. The number of buckets is generally more than the actual key value being loaded. When searching through a key, it is often possible to find the value in constant time.

However, a hash collision occurs when the position information of a hashcode hash of the key is repeated. This can have a disastrous effect on the performance of the HashMap.

Before Java 8, if a collision occurs, the value is often linked directly to the end of all other value in that location, i.e. all the value colliding with each other forms a linked list.

Therefore, in the worst case scenario, the HashMap lookup time complexity degrades to O (n).

However, in Java 8, the processing after the collision was improved. When there is too much conflict in one location, the stored value will form a sorted binary tree, sorted by key hashcode.

Then, at worst, HashMap's lookup time complexity degrades from O (1) to O (Logn).

Although it is a small improvement, it is of great significance:

1, O (n) to O (Logn) time overhead.

2, if the malicious program to know that we use the hash algorithm, then in the pure linked list, it can send a large number of requests to cause a hash collision, and then non-stop access to these keys cause HashMap busy linear lookup, eventually into paralysis, that is, the formation of Denial-of-service attack (DoS).