HashMap in Java causes cpu100% problem in multi-threaded environment

Recent projects in the case of Tomcat occupy cpu100%, the original thought is a dead loop in the code, the background using jstack did dump, found that the system unreasonable use of hashmap led to a dead loop (note is not a deadlock).

The cause of this dead loop is the operation of an unprotected shared variable-a "HASHMAP" data structure. When the "synchronized" is added to all the methods of operation, everything is back to normal.

Is this a JVM bug? It should be said that it is not, this phenomenon has been reported long ago (see more: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6423457). Sun's engineers did not think it was a bug, but rather suggested that "concurrenthashmap" should be used in such a scenario,

Reply to the exact words:

This is a classic symptom of the incorrectly synchronized use Ofhashmap. Clearly, the submitters need to use a thread-safehashmap. If they upgraded to Java 5, they could just use Concurrenthashmap.

So in the development process should pay attention to this, in the multi-threaded environment, try to use Concurrenthashmap.

There may be problems in the area of expansion

Java code

2. void Resize (int newcapacity) {
4. entry[] oldtable = table;
6. int oldcapacity = oldtable.length;
8. if (oldcapacity = = maximum_capacity) {
10. threshold = Integer.max_value;
12. return;
14. }
18. entry[] newtable = new entry[newcapacity];
20. Transfer (newtable);
22. Table = newtable;
24. Threshold = (int) (newcapacity * loadfactor);
26. }

This method itself is not a problem, the problem is transfer (newtable), this method is used to move the data in the oldtable to newtable.

Java code

2. /**
4. * Transfers all entries from the current table to newtable.
6. */
8. void Transfer (entry[] newtable) {
10. entry[] src = table;
12. int newcapacity = newtable.length;
14. For (int j = 0; j < Src.length; J + +) {
16. //(1)
18. Entry<k,v> e = src[j];
20. if (E! = null) {
22. SRC[J] = null;
24. Do {
26. //(2)
28. Entry<k,v> next = E.next;
30. int i = indexfor (E.hash, newcapacity);
32. //(3)
34. E.next = Newtable[i];
36. Newtable[i] = e;
38. e = next;
40. } while (E! = null);
42. }
44. }
46. }

The following analysis may occur, assuming that the original oldtable stored a1,a2 hash value is the same, then the entry list order is:

P1:oldtable[i]->a1->a2->null

P2:oldtable[i]->a1->a2->null

The thread P1 runs to (1) below this line, E=A1 (A1.NEXT=A2), continues to run until (2), next=a2. This time switch to thread P2, thread P2 execute the loop of this list. If the hash value of the A1,A2 in the new table is the same, then the list order at this time is:

Main Memory: Newtable[i]->a2->a1->null

Note that this time, the A1,A2 connection sequence is reversed. Now the CPU is re-P1, after (3) this line: E.next = Newtable[i]; that is: a1.next=newtable[i];

NEWTABLE[I]=A1;

E=A2;

Start the second while loop (E=A2,NEXT=A1):

a2.next=newtable[i];//is A2.NEXT=A1.

Newtable[i]=a2

E=a1

Start the third while loop (E=a1,next=null)

a1.next=newtable[i];//is A1.NEXT=A2.

This time a1.next=a2,a2.next=a1, forming a loopback, which creates a dead loop, when the get operation, Next is never null, resulting in a dead loop.

You can see that there are occasional cycles of death, but once the consequences are very serious, the multi-threaded environment should be used Concurrenthashmap.

HashMap in Java causes cpu100% problem in multi-threaded environment