Master Java Flight Recorder & JProfiler: Low‑Impact Performance Profiling Guide

Generating JFR

Java Flight Recorder (JFR) is a structured logging tool that records a wide range of system‑level events. Like a black box on an aircraft, it continuously captures flight data for incident investigation. JFR records a series of JVM events for diagnosing problems, preserving detailed system information in chronological order. Designed for minimal performance impact, it can safely run in production for extended periods.

Advantages:

Very low runtime overhead, consuming less than 1% of additional resources.

Generated files are small; a typical 10‑minute recording is usually under 1 GB.

Query Java Process

Use the

jps

command.

Or use

ps -ef | grep java

.

Generate JFR File

Start a flight recording with the diagnostic command

jcmd

:

<code>jcmd 84743 JFR.start duration=5m settings=profile filename=~/jfr/xxkk.jfr</code>

Introducing JProfiler

JProfiler is a professional tool for analyzing the internals of a running JVM. It can be used during development for quality assurance and to troubleshoot production issues.

Method Calls – often called “CPU analysis”. Visualizing method calls helps understand what the application is doing and where performance can be improved.

Allocation – analyzes object allocation, reference chains, and garbage collection, aiding in memory‑leak detection and reducing temporary object creation.

Threads and Locks – visualizes lock contention and deadlocks, showing how threads interact with synchronized objects.

High‑Level Subsystems – provides probes for subsystems such as JDBC, allowing you to pinpoint slow SQL statements.

JProfiler offers a desktop UI for interactive analysis and a command‑line mode for automated profiling. Snapshots can be opened in the UI, and integration with build tools enables automated sessions. Note: JProfiler is commercial software; a licensed copy is required for use.

Memory Analysis

Recorded Objects

In memory analysis, recorded objects help identify the most memory‑intensive classes. Only classes whose total object size exceeds a threshold (typically 1 % of the heap) are recorded. This feature is disabled by default in JFR due to its overhead.

Instance count – shows how many objects of a class remain on the heap.

Estimated total size – an estimate of the total size of all instances of the class during the recording.

Allocation Hotspots

The Allocation Hotspots view, together with the Allocation Call Tree, lets you focus on methods responsible for creating selected classes. Like the Recorded Objects view, it supports marking a baseline and observing differences over time. Since the view does not update automatically, click the “Calculate” button to generate a new dataset for comparison.

Calculate hotspots

Hotspot analysis

Hotspot allocation classes

Finding the main issue: byte[] array allocation became a hotspot.

Test Code

<code>/**
 * VM ARG : -Xms64m -Xmx64m
 */
public static void main(String[] args) throws InterruptedException {
    List<byte[]> list = new ArrayList<>(1000);
    // 2KB * 10 * 120 = 2400KB
    // count = 10 * 120 / 10 = 120
    for (int i = 0; i < 10000; i++) {
        Thread.sleep(100);
        byte[] arr = new byte[1024 * 2];
        list.add(arr);
    }
}
</code>

CPU Analysis

Call Tree

Tracing every method call and its stack consumes a large amount of memory and can quickly exhaust resources in a busy JVM. Moreover, the sheer number of calls makes it hard to see which are important. Summarizing the collected data reveals performance problems, showing the relative importance of each method over a time interval.

JProfiler builds a cumulative call tree of all observed call stacks, annotating each node with total time and invocation count. The tree is sorted by total time, allowing depth‑first exploration of the most impactful methods.

Hotspots

If the application runs slowly, you need to locate methods that consume most of the execution time. The call tree sometimes reveals these directly, but often the tree is too large. In such cases, invert the call tree: list all methods sorted by their self‑time, accumulated across all call stacks, and trace back to see how they were invoked. In the hotspot tree, leaf nodes are entry points (e.g., main or thread run). Starting from the deepest node, follow the path upward to the root.

In the back‑trace, the call count and execution time shown for a node refer to how many times the top‑level hotspot was invoked along that path, not the node itself. The numbers represent the hotspot’s contribution to the top‑level node.

This case’s CPU hotspot is caused by a regular‑expression operation.

Test Code

<code>static String pattern = " ^([\\u4e00-\\u9fa5]+)((·[\\u4e00-\\u9fa5]+)+|([\\u4e00-\\u9fa5]+))$";
static String defaultName = "张三·无论其是看都看呐阿斯顿啊·萨肯萨肯打开你发都看啊看你发个卡看那可能发看那个可能看呐";

public static void main(String[] args) throws InterruptedException {
    int time = 1;
    String result;
    while (true) {
        if (time > 0) {
            Thread.sleep(time);
        }
        result = defaultName.matches(pattern) ? "姓名合法" : "姓名不合法";
    }
}
</code>

Reference Documents

jcmd command reference: https://docs.oracle.com/javacomponents/jmc-5-5/jfr-command-reference/diagnostic-command-reference.htm

Generating JFR files: https://docs.oracle.com/javacomponents/jmc-5-5/jfr-runtime-guide/run.htm

JProfiler Chinese manual: https://www.ej-technologies.com/resources/jprofiler/v/13.0/help_zh_CN/doc/main/memory.html