High CPU usage in production.

Hook: A high-CPU alert is the kitchen smoke alarm of production: don’t add more chefs first — find the burning pan.

Question: High CPU usage in production.

Answer: In a Spring Boot service, high CPU usually means one or more threads are burning time in a hot loop, expensive parsing, serialization, regex, garbage collection, or lock spinning. First confirm whether the problem is the JVM process, the container, or the node; then use Actuator metrics and a thread dump to identify the hot path. The fix is usually to remove the expensive work, add caching or batching, reduce noisy logging or polling, and only scale out after you know the root cause.

Interview-Ready Answer: “When I see high CPU in production, I first confirm whether the load is on the JVM, the container, or the node. Then I check Spring Boot metrics like process.cpu.usage and take a thread dump to find the hottest stack trace. In practice I want the exact hot method or GC pattern before I change anything, because blindly adding threads or replicas can make CPU and latency worse.”

What high CPU really means

CPU is the workhorse of the machine. When it is near 100% for a sustained period, the app is spending too much time doing compute work, not waiting on network or disk. In Linux, 100% usually means one full core, so a Java process can show 300% on a 4-core box and still be normal if it is truly using three cores. In Kubernetes, also check whether the pod is being throttled (CPU limited by cgroups, the Linux container quota system), because a pod can be slowed down even if the node still has free cores.

Debug it in the right order

1. Confirm the scope. Check host CPU, pod CPU, and JVM process CPU separately. Spring Boot does not create CPU problems by itself; it reveals the problem. If only one pod is hot, suspect a bad deployment, a data-dependent request, or a noisy tenant.
2. Read the metrics first. With Actuator + Micrometer, look at process.cpu.usage and system.cpu.usage. These are ratios from 0.0 to 1.0, not percentages. Add jvm.threads.live, jvm.gc.pause, and request latency metrics so you can tell CPU pressure from garbage collection or traffic spikes.
3. Take a thread dump. Use jcmd <pid> Thread.print, /actuator/threaddump, or kill -3. A thread dump is a snapshot of every thread right now. Look for many RUNNABLE threads with the same stack trace. RUNNABLE means the thread is able to run or is running; it does not mean “blocked”.
4. Profile the hot path. If one method keeps appearing, use Java Flight Recorder (JFR) or async-profiler to sample over time. A thread dump tells you where the smoke is; a profiler tells you which flame is burning longest. JFR usually has low overhead, often around 1–2% when used well, which is why it is safe enough for production in many cases.
5. Fix the root cause. If the code is accidentally O(n²) (work that grows much faster than input size), change the algorithm or data structure. If the same result is recomputed repeatedly, cache it. If the CPU comes from JSON serialization, regex backtracking, or excessive logging, reduce the work. If the traffic is legitimate and the code is already efficient, then scale out.
6. Verify under the same load. Re-run the same request pattern and confirm CPU, p95 latency, and error rate improve together. Add alerts on sustained CPU, not one-second spikes, because some spikes are harmless and self-correcting.

How to read the symptoms

Tools at a glance

Practical interview detail: if a Tomcat app is CPU-heavy, remember the default max worker thread count is commonly 200. Adding even more threads can increase context switching, which is the overhead of the OS constantly swapping work between threads, and that can make CPU usage worse instead of better.

Real-World Story: A checkout service in a Spring Boot e-commerce app started hitting 90% CPU during a flash sale. Users saw slow payment confirmation, p95 latency jumped from 120 ms to 3–4 seconds, and Kubernetes restarted pods because the readiness probe timed out. The logs were mostly clean, which made the problem feel mysterious until a thread dump showed many request threads stuck in a regex-based coupon parser. The fix was to precompile the pattern, cache repeated lookups, and reduce the amount of per-request logging. After that, CPU dropped, response time stabilized, and the same pod count handled the sale comfortably.

What went wrong in the outage was not “Spring Boot is slow”; it was a small piece of expensive code running for every request. That is the key lesson: production CPU issues are usually a hot path problem, not a framework problem.

Follow-up & Tricky Questions:

• How do you tell CPU saturation from GC thrash? CPU saturation usually shows hot application stacks in RUNNABLE threads; GC thrash shows frequent garbage collection activity, allocation pressure, and pause logs. JFR or GC logs confirm it quickly.
• Why is a thread dump useful if CPU is already high? A thread dump is a fast snapshot of what every thread is doing right now. Repeating it two or three times a few seconds apart often shows the same method burning CPU.
• Would you just add more pods? Only after the hot path is understood. Replicas help capacity, but if each request is too expensive, you just spread the waste across more machines.
• When does high CPU mean too many threads? When too many request threads are runnable at once, the OS spends time on context switching instead of useful work. In Spring Boot, a big Tomcat pool can make CPU-heavy endpoints worse, not better.
• What if the app is fine but the node is hot? Then look for noisy neighbors, a CPU limit, or another workload on the same host. In containers, throttling can make a healthy app look unhealthy.
• Tricky: Is a single spike always a problem? No. Short spikes during cache warm-up or burst traffic can be normal. The dangerous pattern is sustained CPU with rising latency or error rate.
• Tricky: Does high latency always mean high CPU? No. Latency can come from slow databases, network waits, or lock contention with low CPU. Always check the CPU signal before assuming the app is compute-bound.
• Tricky: Is Thread.sleep a fix? No. Sleeping only hides the symptom. It lowers current CPU for that thread, but it does not remove the expensive work and often increases user-facing latency.

Common Mistakes:

• Jumping straight to scaling. Correction: first find the hot method or GC pattern; scaling only makes expensive code more expensive at a larger cost.
• Reading only one metric. Correction: pair CPU with thread dumps, latency, GC, and request rate so you can tell compute from contention or allocation churn.
• Ignoring container limits. Correction: compare process CPU to pod limits and node CPU, because throttling can mimic a code problem.
• Adding more threads to a CPU-bound app. Correction: more threads often mean more context switching and worse throughput; fix the work, not just the thread count.

Memory Hook: Think: measure, isolate, fix. A hot CPU is a smoke alarm, not the fire itself; your job is to find the exact pan on the stove before you open more burners.

Cheat Sheet:

• Check whether the CPU is hot on the node, pod, or JVM process.
• Use Actuator metrics like process.cpu.usage and system.cpu.usage.
• Take thread dumps and look for repeated RUNNABLE stacks.
• Use JFR or async-profiler for the exact hot method.
• Fix repeated work with caching, batching, or a better algorithm.
• Scale only after the hot path is understood.

Practice Tasks:

• Run the demo app and compare /api/primes/slow?n=5000 with /api/primes/cached?n=5000.
• While hitting the slow endpoint, capture a thread dump with jcmd <pid> Thread.print and identify the busy stack.
• Expose Actuator metrics and watch process.cpu.usage while you generate load with a tool like wrk or ab.