I’ve used Java for five years and learned a lot of fancy tricks, but I never seemed to have delved into manual troubleshooting techniques. Recently, I happened to read a book titled Server-Side Development: Technologies, Methods, and Practical Solutions. Although this book isn’t very inspiring for employees of Company A—since we use the middleware, technologies, stability components, and design solutions described in the book every day—I still read it word for word in a single afternoon. However, the section on troubleshooting Java thread issues was still a gap in my technical knowledge, so I put it into practice briefly and documented it here.
Step 1: top
You can see the processes with high CPU usage. Generally, scenarios requiring a dump occur when an issue arises in production services, so the Java process ranks at the top. Here, let’s take process ID 12200 as an example.
Step 2: top -H -p 12200
This allows you to see the thread with the highest CPU usage within process 12200, and you can note down the thread ID. Here, let’s take thread ID 3868 as an example.
Step 3: printf “%x” 3868
Convert 3868 to hexadecimal, getting f1c.
Step 4: jstack 12200 | grep f1c
This will show which piece of code caused the issue, so you can check the corresponding code accordingly—which is also why thread pools should be given meaningful names. You can also use grep f1c -A 15 to view the next 15 lines of the call stack.
