The 30 second answer
First I find which threads are burning CPU. I take a few thread dumps a few seconds apart and look for the same stacks running, then record a short Java Flight Recorder profile to see hot methods and GC activity. With flat traffic the usual causes are GC thrashing as the heap fills, a busy loop or retry storm, a regex or serialization hot spot, or a background job.
First I find which threads burn CPU. jcmd <pid> Thread.print gives thread dumps; I take a few, a few seconds apart, and look for the same stacks running. Then I record a JFR profile (jcmd <pid> JFR.start duration=60s filename=cpu.jfr) and look at hot methods and GC activity. Usual causes with flat traffic: GC thrashing as the heap fills, a busy loop or retry storm, a regex or serialization hot spot, or a background job. Follow-up: How do you tell GC from app code? (GC events and pause time in JFR, or jcmd <pid> GC.heap_info.) Editor's note: on Linux, top -H -p <pid> shows per-thread CPU; convert the thread ID to hex to match the nid in the dump.