Shulou(Shulou.com)05/31 Report--

This article focuses on "Hashmap non-thread safety on how to deal with hash value conflicts", interested friends may wish to take a look. The method introduced in this paper is simple, fast and practical. Let's let the editor take you to learn how to deal with hash value conflicts in Hashmap non-thread safety.

How to deal with hash value conflict

We all know that it is a storage structure based on hash value and can be digested in constant time. It is widely used for efficient key-value storage in various situations. Here are a few questions. First of all, what should I do if there is a hash conflict? I believe that many people can say that conflicts can be resolved through linked lists without thinking. Is to store the same hash value in a linked list mounted at that location. But this leads to a new question, how does a key get the desired value on the linked list if its hash value conflicts? This is going to look at the storage structure of hashmap. Each key-value is encapsulated in an entity, and this entity is actually stored in the map. This stores both value and key. All you need to do to take a value on a linked list is to compare whether key is equal. Another question arises as to why it is recommended to override the equal and hash methods of key. Rewriting the hash method can ensure that different objects are used for different hash values, thus reducing conflicts, while rewriting equal can ensure that there is no error coverage in the event of conflicts.

Hashmap's put method final V putVal (int hash, K key, V value, boolean onlyIfAbsent, boolean evict) {Node [] tab; Node p; int n, I; if ((tab = table) = = null | | (n = tab.length) = = 0) / / is not initialized, and the initialization calls the resize () method n = (tab = resize (). Length). If ((p = tab [I = (n-1) & hash]) = = null) tab [I] = newNode (hash, key, value, null); / / this position has no value and is inserted directly. The function of rewriting hash method is reflected in the conflict Node e; K k of else {/ / If (p.hash = = hash & & (k = p.key) = = key | | (key! = null & & key.equals (k) / / found the value e = p; else if (p instanceof TreeNode) / / event tree node of the key equal and inserted it into the tree. After the number of jdk8 conflicting nodes reaches a certain value, use the tree structure to store e = ((TreeNode) p) .putTreeVal (this, tab, hash, key, value), else {for (int binCount = 0; + + binCount) {/ / always find the end of the linked list, insert kmurv into if ((e = p.next) = = null) {p.next = newNode (hash, key, value, null); if (binCount > = TREEIFY_THRESHOLD-1) / /-1 for 1st treeifyBin (tab, hash) / / whether it needs to be changed to break;} if (e.hash = = hash & & (k = e.key) = = key | | (key! = null & & key.equals (k) break; p = e }} if (e! = null) {/ / existing mapping for key V oldValue = e.value; if (! onlyIfAbsent | | oldValue = = null) e.value = value; afterNodeAccess (e); return oldValue;}} + + modCount If (+ + size > threshold) resize (); afterNodeInsertion (evict); return null;}

The above code fully demonstrates the role of key in rewriting equal. HashMap uses the value of key to get the value, so make sure that the hashcode of the same key cannot be changed at any time. This is why it is recommended that key is an immutable object, such as a string object. If the key is an object and the hashcode of the key is changed due to the change of the internal value during the run, then the value in the map will be lost forever.

Non-thread safety embodiment

This is a discussion about kv, followed by another common topic about HashMap-thread safety. Most people know that it is not thread-safe. But if you ask you where it is not thread-safe, I am afraid it will stumble a group of people.

The first thing that comes to mind is that there is a conflict during multithreaded insertion, where multiple threads are inserted at the same time, but some of these values conflict again. When inserting, everyone sees that there is no value in this position, so they all insert, so it is certain that there will be a value overwrite, and the external performance is that the value is lost. If this position already has a value when you start the insertion, a value override will still occur during the insertion of the linked list.

In addition, there is the problem of simultaneous expansion. Because HashMap will automatically expand when there is insufficient space, and its size will double that of the previous one. Copy the previous values to the new array at the same time. The conflict chain is also replicated. If multiple threads insert and see that the capacity needs to be adjusted at the same time, the resize method is called. Then it is difficult to predict what will happen to the arrival at the bottom.

So this is the second aspect of HashMap's non-thread safety. Of course, there may be data inconsistencies between reading and writing a value at the same time. This is also a sign of non-thread safety.

At this point, I believe you have a deeper understanding of "Hashmap non-thread safety on how to deal with hash value conflicts". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.