HashMap in JDK8 still loops forever!
If you’ve heard about the problem that HashMap has solved since JDK8, it doesn’t cause server load spikes, although HashMap still says threads are unsafe.
However, this is not the case. Have you ever known a red-black tree ring scene, =v=
Today, when I checked the monitoring, I found that the load of a certain machine soared
Feel the problem is not right, SSH big method login machine, top, top-HP, jSTACK, jMAP quadruple hit save stack, CPU using the highest thread, memory information ready to analyze.
Start by looking at the stack information for the threads that use the most CPU
cat stack | grep -i 34670 -C10 --color
Copy the code
HashMap, for god’s sake, is probably dead loop, but we used JDK8 to solve the problem of dead loop in 8 by replacing linked lists with closed stacks. Doubt, continue to read.
According to the stack information, the root method is the problem, so open the HashMap source
Well, the load is going up, and the code has a for statement, and I think it’s a dead loop, and the only way to get out of this for statement is if the parent of two red-black tree nodes references each other.
However, this is all my guess, I have no proof. It also took a lot of time for me to follow the red-black tree code, and I needed to quickly verify my guess.
I dumped the heap information earlier. I generated the HTML memory information page using the jhat command
Then type http://localhost:7000 to see
I first look for the object in the business code that holds the HashMap and then click on it to look for internal information
Because the data is in the table, click on the Table field to see its contents
There is only one TreeNode in the table, which must be a red-black tree
Click in to see
Click on the parent field information
The Parent references of 0x72745d828 and 0x72745d7b8 TreeNode nodes are each other.
In the future, I plan to delve into what red-black tree scenarios might be responsible for this.
Finally, do not use HashMap, ConcurrentHashmap in any concurrent scenario