Java Academy · Lesson

Analyzing with JDK Mission Control

Read JFR recordings.

Analyzing with JDK Mission Control is a free Java Academy lesson on CoddyKit — lesson 3 of 4. You can read the complete lesson below for free — then practise it hands-on in the browser with a built-in code editor and a 24/7 AI tutor. It is part of the Java Academy learning path, one of 4 lessons in the course, and your progress syncs across the web and the CoddyKit app.

What is JMC?

JDK Mission Control (JMC) is the graphical tool for analyzing JFR recordings.

It opens a .jfr file and turns raw events into navigable views: hot methods, GC behavior, lock contention, allocation, and more. It also includes an Automated Analysis page that flags likely problems.

Getting JMC

JMC is a standalone download (it was unbundled from the JDK after JDK 8).

Grab it from the Adoptium or Oracle JMC builds, launch it, and open your .jfr file with File > Open File. No agent or restart of your app is needed — you analyze the already-captured recording.

The Automated Analysis Page

The first thing JMC shows is Automated Analysis: a set of heuristics that score your recording.

It highlights things like long GC pauses, high allocation, blocked threads, and primitive-to-object boxing. Each finding has a severity and a short explanation — a great starting point before you dig in manually.

Method Profiling View

The Method Profiling page aggregates execution samples into a call tree.

Methods with the highest self time are your CPU hotspots. You can switch between top-down (caller to callee) and bottom-up (hot method first) views to understand both what is slow and who calls it.

Flame Graphs

JMC renders stack samples as a flame graph: width is proportional to time spent.

Wide plateaus near the top of the graph are where the CPU actually spends its cycles. This visual makes it obvious which call path dominates, far faster than reading a sorted table.

Garbage Collection View

The GC pages show pause durations, frequency, and which collector ran.

Look for long or frequent pauses that hurt latency. A high allocation rate usually correlates with frequent young-generation GCs — the fix is reducing object churn, not changing the collector.

Allocation Hotspots

JMC's TLAB Allocations view ranks where objects are created.

Pair this with the stack trace to find the exact line allocating in a hot loop. Often a small change — reusing a buffer or avoiding autoboxing — cuts GC pressure dramatically.

import java.util.ArrayList;
import java.util.List;

public class Main {
    public static void main(String[] args) {
        // Autoboxing: each add boxes an int into an Integer object
        List<Integer> boxed = new ArrayList<>();
        for (int i = 0; i < 5; i++) boxed.add(i);
        System.out.println("Boxed " + boxed.size() + " Integers");
        System.out.println("JMC allocation view would flag this hotspot");
    }
}

Lock Contention

The Lock Instances and Java Monitor views reveal threads waiting on synchronization.

If many threads block on the same monitor, that lock is a scalability bottleneck. JMC shows the contended object and the waiting stack traces so you can target the right critical section.

Thread and Latency Views

The Threads page shows each thread's timeline: on-CPU, parked, waiting on IO, or blocked.

This is how you confirm whether a slowdown is CPU-bound or IO-bound — exactly the distinction from the bottleneck lesson. Wide 'waiting' bands mean you are IO- or lock-bound, not compute-bound.

From Finding to Fix

The workflow: open the recording, read Automated Analysis, drill into the flagged area (method profiling, GC, or locks), confirm with the flame graph and thread view, then form a hypothesis.

Change one thing, re-record, and compare against your baseline. JMC turns a binary file into actionable insight.

Comparing Recordings

To prove an optimization worked, compare a 'before' and 'after' recording.

Capture a baseline JFR, apply one change, capture another, and open both in JMC. Look at the same views — method profiling, GC, allocation — side by side. A real improvement shows up as reduced self time, fewer GC pauses, or a lower allocation rate. If nothing moved, revert the change.

Quick Check

In JMC's method profiling and flame graph views, what does a method's self time (or a wide plateau at the top) indicate?

Recap

JMC reads JFR recordings and makes them actionable:

Automated Analysis flags likely problems up front.
Method profiling and flame graphs reveal CPU hotspots via self time.
GC and allocation views expose memory churn.
Lock and thread views distinguish CPU-bound from IO/lock-bound.
Drill in, hypothesize, fix one thing, re-record, compare.

Frequently asked questions

Is the “Analyzing with JDK Mission Control” lesson free?

Yes — the full text of “Analyzing with JDK Mission Control” is free to read here on the web, and the Java Academy course includes 4 lessons in total. To practise it interactively (a built-in code editor and a 24/7 AI tutor) and unlock the rest of the Java Academy course, upgrade to CoddyKit PRO.

What will I learn in “Analyzing with JDK Mission Control”?

Read JFR recordings. You practise Java Academy with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.

Do I need any experience to start Java Academy?

No prior experience is required. Java Academy on CoddyKit is structured for beginners through advanced learners; this is — lesson 3 of 4, so you can start here or from the beginning and move at your own pace.

How long does the “Analyzing with JDK Mission Control” lesson take?

Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.

Can I write and run code in this Java Academy lesson?

Yes. Every Java Academy lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.

All lessons in this course

← Back to Java Academy