A Java service in production suddenly pegs the CPU at 100%. What do you do in the first ten minutes?

Three causes cover nearly everything. First, a GC death spiral: the heap is nearly full, full GCs run back to back reclaiming almost nothing, CPU is at 100% while the application barely progresses. The tell is jstat showing old-gen occupancy pinned high with the full-GC count climbing fast. Second, an infinite loop or an algorithm exploding on unusual input, visible directly in that thread's stack. Third, lock contention with threads spinning, usually obvious when jstack shows dozens of threads at the same line.

The procedural point is taking SEVERAL jstacks a few seconds apart, not one. One snapshot gives you a moment; three tell you which thread is STUCK in the same place — and that's the one worth investigating. If memory is suspected, jmap -dump:live before restarting, accepting that it causes a long pause, because without the dump you'll be standing in this exact spot again next time.

At senior level, a good answer also names what should be arranged BEFORE the incident: Java Flight Recorder running continuously at low overhead, so when something happens you already have the minutes leading up to it instead of starting to measure while everything burns. Always-on JFR costs about 1% and is one of the easiest trade-offs to justify in JVM operations.

One last thing: restarting is a legitimate action while users are affected — just do it after capturing the dumps. Restore service first, but don't let restoring it destroy your ability to prevent the next one. Getting that order right scores more than naming tools.