Profiling a Java Application to Find Performance Bottlenecks

Intermediate·2 min read·

Fast recall

Quick revision

Core answer

Profile using async-profiler or JFR for CPU/memory flamegraphs, identify hot methods, then correlate with APM traces to pinpoint the root cause before optimizing.

Interview Answer2 min

Profiling a Java application starts with measuring before changing anything — a flamegraph or thread dump tells you where time is actually spent, which is almost never where you expect.

CPU profiling with async-profiler

async-profiler samples the call stack at regular intervals without the overhead of traditional JVMTI profilers — which means it's safe to run in production for short periods without perceptibly increasing latency
./profiler.sh -d 30 -f flamegraph.html PID captures 30 seconds and generates an interactive flamegraph; the widest boxes at the top of the flamegraph are the methods consuming the most CPU
Common CPU hotspots in Spring Boot: JSON serialization/deserialization in a tight loop (recreating ObjectMapper), Hibernate N+1 generating thousands of SQL calls, string concatenation in logging without a guard

Memory profiling with JFR

Java Flight Recorder (JFR) is built into the JDK and has near-zero overhead — jcmd PID JFR.start duration=60s filename=recording.jfr captures allocation, GC, thread events, and more for 60 seconds
Open the recording in JDK Mission Control; the Allocation tab shows which call sites allocate the most objects; the GC tab shows pause durations and frequencies
Short-lived objects that escape to old gen are the most common memory footprint problem — they force more frequent full GCs

Heap dump analysis

When you suspect a memory leak: jmap -dump:live,format=b,file=heap.hprof PID captures a heap snapshot; open in Eclipse MAT or VisualVM
The "Dominator Tree" in Eclipse MAT shows the objects retaining the most heap; a class whose instance count grows with each request indicates a leak (typically static collections, unclosed resources, or ThreadLocal values)

Thread dump for deadlock and blocking

jstack PID or kill -3 PID generates a thread dump; look for threads in BLOCKED state (contended lock) or WAITING state (waiting indefinitely); a stack trace showing all threads blocked on the same monitor is a deadlock
Repeat the thread dump 3 times at 5-second intervals — threads consistently blocked on the same call stack across all three dumps are real blocking, not transient waits

Interview-ready guide

Interview answer

Profiling a Java application starts with measuring before changing anything — a flamegraph or thread dump tells you where time is actually spent, which is almost never where you expect.

CPU profiling with async-profiler

async-profiler samples the call stack at regular intervals without the overhead of traditional JVMTI profilers — which means it's safe to run in production for short periods without perceptibly increasing latency
./profiler.sh -d 30 -f flamegraph.html PID captures 30 seconds and generates an interactive flamegraph; the widest boxes at the top of the flamegraph are the methods consuming the most CPU
Common CPU hotspots in Spring Boot: JSON serialization/deserialization in a tight loop (recreating ObjectMapper), Hibernate N+1 generating thousands of SQL calls, string concatenation in logging without a guard

Memory profiling with JFR

Java Flight Recorder (JFR) is built into the JDK and has near-zero overhead — jcmd PID JFR.start duration=60s filename=recording.jfr captures allocation, GC, thread events, and more for 60 seconds
Open the recording in JDK Mission Control; the Allocation tab shows which call sites allocate the most objects; the GC tab shows pause durations and frequencies
Short-lived objects that escape to old gen are the most common memory footprint problem — they force more frequent full GCs

Heap dump analysis

When you suspect a memory leak: jmap -dump:live,format=b,file=heap.hprof PID captures a heap snapshot; open in Eclipse MAT or VisualVM
The "Dominator Tree" in Eclipse MAT shows the objects retaining the most heap; a class whose instance count grows with each request indicates a leak (typically static collections, unclosed resources, or ThreadLocal values)

Thread dump for deadlock and blocking

jstack PID or kill -3 PID generates a thread dump; look for threads in BLOCKED state (contended lock) or WAITING state (waiting indefinitely); a stack trace showing all threads blocked on the same monitor is a deadlock
Repeat the thread dump 3 times at 5-second intervals — threads consistently blocked on the same call stack across all three dumps are real blocking, not transient waits

03 · Deep dive