To locate performance bottlenecks in Java applications, you can use a combination of JFR and JMC tools. 1. Ensure that the JDK version supports and enables JFR; 2. Record data dynamically through the command line or runtime; 3. Use JMC to analyze key indicators such as CPU, memory, GC and hotspot methods; 4. Use events and method calls to find specific bottlenecks, such as Full GC, thread blocking or I/O problems; 5. Pay attention to setting the recording time reasonably, avoiding long-term opening, and understand interface and function limitations.

Java application performance tuning is often not based on guessing, but on tools. JFR (Java Flight Recorder) and JMC (Java Mission Control) are a very practical combination, especially useful when troubleshooting performance issues in the production environment. They can help you see the details of the program running, such as GC behavior, thread state, time-consuming method execution, etc.

Let’s start from several practical perspectives and talk about how to use this set of tools to locate performance bottlenecks.

How to enable JFR and record Flight once

To use JFR, you must first make sure your JDK version supports it. OpenJDK 11 and above already has built-in JFR community version, while Oracle JDK comes with full features. When starting the application, add parameters to enable:

• Startup parameters example:
  • -XX: UnlockCommercialFeatures
  • -XX: FlightRecorder

There are two ways to record: one is to start recording directly through the command line, and the other is to dynamically attach it during operation.

For example, if your application is already running, you can trigger a fly through jcmd :

 jcmd <pid> JFR.start duration=60s filename=myrecording.jfr

This command will record the data for the next 60 seconds and save it as a myrecording.jfr file. This process has little impact on system performance and is suitable for temporary sampling in production environments.

What is the most effective way to open JFR data using JMC to see

After getting the .jfr file, open it with JMC and you can see a bunch of charts and events. But it may be a bit dazzled at the beginning, so it is recommended to focus on the following parts:

• Overview page : You can see the CPU usage, heap memory changes, GC frequency, etc. during the entire recording period, and quickly determine whether there are obvious abnormalities.
• Event Browser : Here lists all recorded event types, such as "Allocation in new TLAB" that can be used to analyze object allocation.
• Method Profiling : If you want to check hotspot methods, this item is very useful. It shows the call time and proportion of each method, helping you find the method stack with the longest execution time.

Tips: When viewing method calls, remember to switch to the "Hot Methods" view, so it is easier to find out which methods take up a lot of CPU time.

How to find performance bottlenecks in combination with JFR data

With the data, the focus is on how to interpret it. For example, if you find that an interface is slower to respond, you can search for it as follows:

1. Check whether there are frequent Full GCs that cause application pauses;
2. Check whether there are threads blocking for a long time or waiting for resources;
3. Check the hotspot method, whether a certain business logic consumes too much CPU;
4. Analyze whether I/O operations have become a bottleneck, such as slow database queries and high network latency.

To give a simple example: If you find that "Socket Read" events are frequent and time-consuming, it may be caused by slow response of external services or instability in the network. At this time, you can further investigate the call link instead of just staring at the Java code itself.

Notes and common misunderstandings

Although JFR JMC is very powerful, there are some easy places to get stuck:

• Don't keep on running JFR: Although the overhead is not large, long-term recording will generate a large amount of data, affecting disk space and performance.
• The recording time should not be too short: for example, only 5 seconds are recorded, and key events may be missed; it is recommended to adjust according to the scene, generally 30 seconds to 2 minutes are more appropriate.
• The JMC interface is a bit old: it may not be intuitive for the first time, so I will get used to it after clicking a few more times.
• Some advanced features are only available for commercial versions: for example, more detailed thread analysis, memory leak detection and other functions are not available in the community version.

Basically that's it. Once you master the basic process, you will find that this set of tools is very efficient in diagnosing complex problems and does not require additional third-party dependencies.

The above is the detailed content of Java Performance Profiling with JFR and JMC. For more information, please follow other related articles on the PHP Chinese website!