CPU Profiling

CPU profiling identifies which methods consume the most processor time while an application runs. It helps Java backend engineers locate CPU-intensive code so performance work can target measurable hotspots.

A CPU profiler observes application execution and attributes processor activity to methods or call stacks. The result helps reveal hotspots: parts of the program responsible for a significant share of CPU consumption.

Sampling profilers periodically inspect running threads and record where they are executing. They usually have relatively low overhead and are useful for understanding production-like workloads. The resulting samples can be grouped by method or call stack to show where CPU time is concentrated.

Instrumentation-based profilers insert measurement logic around method execution. This can provide detailed timing information, but the added work may affect application behavior and performance. For that reason, sampling is often preferred when the goal is to understand realistic CPU behavior.

CPU profiling is different from measuring elapsed response time alone. A slow request might spend much of its time waiting for a database, network, lock, or other resource rather than consuming CPU. A profiler should therefore be used with the relevant workload and interpreted alongside metrics such as latency, throughput, allocation, and I/O.

Key points

Interview questions

What is CPU profiling, and why would you use it?

CPU profiling is a way to determine which methods or call paths consume substantial processor time while an application runs. It is useful when an application is CPU-bound or when a performance investigation needs to locate computational hotspots. The profiler provides evidence about where execution effort is concentrated instead of relying only on code inspection. That information can guide targeted optimization.

What is the difference between sampling and instrumentation profilers?

A sampling profiler periodically records what running threads are executing and aggregates those observations. Instrumentation adds measurement logic around execution points, such as method calls, to collect more direct timing information. Instrumentation can provide greater detail but may introduce more overhead and perturb the workload. Sampling is therefore commonly useful when minimizing profiling impact matters.

A Java service has high CPU usage. How would you investigate it?

I would first reproduce or observe the issue under a representative workload and confirm CPU saturation with runtime metrics. I would then capture CPU profile data and inspect the hottest methods and call stacks. Next, I would determine whether the hotspot is expected computation, excessive looping, synchronization-related behavior, serialization, parsing, or another workload characteristic. After making a targeted change, I would rerun the same workload and compare the measurements.

Why might a slow Java request not show a corresponding CPU hotspot?

A request's latency can include substantial time waiting for resources rather than executing instructions on a CPU. Examples include database calls, network I/O, blocking queues, locks, and scheduler delays. A CPU profile may therefore show little processor activity during the period responsible for the latency. The investigation should combine CPU profiling with latency traces, I/O measurements, thread-state information, and other relevant telemetry.