HashMap get () method, wrong concurrency causes high CPU and load

A solution to the problem on the line

The online discovery service CPU uses up to 98%, loads as much as 200, 64 core CPUs, and the following describes the resolution process:

1.top command isolated process PID with high CPU consumption

2. Get the dump file using jstack-l pid >dump.txt

3. Use Top-h to query the consumed resource's thread number, TID (decimal thread ID), and convert to 16 binary

4.cat Dump.txt | grep-10 tid (16 binary) query the upper and lower 10 lines of the process number, locate the problem and resolve the problem

=====================================================

1. Use the top command

2.jstack-l pid >dump.txt Get dump File

3. Use Top-h to query the consumed resource's thread number, TID (decimal thread ID), convert to 16, 10587 to 16, and 295B to lowercase for 295b

4.cat Dump.txt | grep-10 tid (16 binary) query the upper and lower 10 lines of the process number, locate the problem and resolve the problem

Cat Dump.txt | Grep-10 295b

Finding the problem in HashMap's Get method, count found that there are more than 200 runnable states in the Get method called HashMap, After finding the No. 592 line of Servicebuilder found that a common static method uses a class global variable HashMap as a shared variable is used concurrently, the No. 592 line is the Get method, after finding found in 1.7 get method has E.next () method causes an infinite loop of the CPU. So the hashmap changed to Concurrenthashmap. The problem should be solved, to be on-line verification. (Note that the problem does not necessarily occur in 100%)

See also (circular bug about HashMap): http://ifeve.com/hashmap-infinite-loop/

HashMap get () method, wrong concurrency causes high CPU and load