Java interview questions: High concurrency environment, HashMap may appear fatal problems. Note: This is the JDK8 version __java

Concept of the 1:rehash concept.
Rehash is a step in the expansion of HashMap.

The capacity of the HashMap is limited. When the hashmap reaches a certain degree of saturation, the probability of the key mapping position will increase gradually when the insertion of several elements is made.

at this point, the HASHMAP needs to extend its length, that is, to resize

There are two factors affecting the occurrence of resize:
1.Capacity (current length of hashmap – capacity)
The current length of the HashMap. As the previous issue once said, the length of a hashmap is a power of 2.

2.LoadFactor (load factor)
HashMap load factor, the default value is 0.75f.

the conditions for measuring whether hashmap are resize are as follows:
hashmap.size >= Capacity * loadfactor (By default = = Original length * 0.75)

HashMap's Resize method specifically did something.

1. Capacity Expansion
Creates a new entry empty array that is twice times the length of the original array.

2.ReHash
Iterate through the original entry array and hash all the entry into the new array. Why do you want to hash it again? As the length expands, the hash rules change as well.

Let's review the hash formula:
index = hashcode (Key) & (Length-1)

When the original array length is 8 o'clock, the hash operation is done with the 111B (representing the binary 7), and the new array length is 16,hash and 1111B (representing the binary 15). hash results are obviously different .

The Java code for rehash is as follows:

/**
 * Transfers all entries from the current table to newtable.
 *
/void Transfer (entry[] newtable, Boolean rehash) {
    int newcapacity = newtable.length;
    for (entry<k,v> e:table) {while
        (null!= e) {
            entry<k,v> next = e.next;
            if (rehash) {
                E.hash = NULL = = E.key? 0:hash (E.key);
            }
            int i = indexfor (E.hash, newcapacity);
            E.next = Newtable[i];
            Newtable[i] = e;
            e = Next;}}

notice what kind of problems the rehash may have hashmap in multithreading.

Suppose a HASHMAP has arrived at the critical point of the resize. There are two threads A and b at this time, and the HashMap is put on at the same time:

at this point the resize condition is reached, the first step of each of the two threads Rezie, that is, expansion:

At this point, two threads have come to the rehash step. Let's review the rehash code:

If thread B traverses the Entry3 object at this point, the thread is suspended just after the line of code in the red box is executed.
in the case of thread B
: E = Entry3 Next =entry2
At this point thread A is rehash, and when rehash is finished , the results are as follows ( E and next in the figure, representing two references to thread B ):

Until this step, there seems to be nothing wrong. Then thread B resumes and continues to execute its own rehash.
The state of thread B just now is:e = Entry3 next = Entry2

When executing to the line above, obviously I = 3, because the hash result of thread A for Entry3 is also 3.

We proceed to these two lines, Entry3 placed the array of thread B labeled 3, and E points to Entry2.
At this point E and next are pointing to the following:
e =entry2 next = Entry2
The overall situation is shown in the following illustration:

Next is a new round of loops, followed by a line of code in the red box:

e = Entry2
next = Entry3
The overall picture is as follows:

Next, perform the following three lines, inserting the Entry2 into the header node of thread B's array by using the header interpolation:

The overall picture is as follows:

The third loop begins, and the Code to the red box is executed:

E = Entry3
Next = Entry3.next = null

The last step, when we execute the following line, the moment of miracles is here.

Newtable[i] = Entry2
E = Entry3
Entry2.next = Entry3
Entry3.next = Entry2
There is a ring in the list.
The overall picture is as follows:

at this point, the problem has not been directly generated. When call get looks for a nonexistent key,
and the hash result of this key is exactly equal to 3, because the position 3 with the ring list, so the program will enter the dead loop.

This situation, can not help but reminiscent of a classic interview question:
comic algorithm: How to determine the link list has a ring.
How to eliminate this situation.

Summarized as follows

1.Hashmap needs to be resize when inserting too many elements.
The condition of resize is hashmap.size >= Capacity * loadfactor.

2.The resize of HashMap contains two steps of dilatancy and rehash, rehash may form a linked list ring in concurrent situations .

The head interpolation of the chain will reverse the order of the list in the original hash bucket. The original order was reversed by another thread A at the time of concurrency, the thread B is suspended after recovery after the expansion of the node and order to continue to complete the first cycle, followed by a thread expansion of the chain list in order to rearrange the order of the list, and eventually formed a ring.