Quick checklist before you press record

Yes this is a tutorial and yes you can skip straight to the jcmd part if Eclipse gives you attitude. First make sure your JDK actually includes Java Flight Recorder and that your Eclipse build has the JFR launch integration or a plugin that adds JFR controls. Modern OpenJDK builds and Oracle JDK usually include JFR. If you are on ancient Java please upgrade or accept your fate.

Enable JFR in your Eclipse launch configuration

Open the Run or Debug launch configuration for your project and look for a Flight Recorder tab or a place to add JVM options. If the UI appears you can enable the recorder, pick a profile or custom settings, and set the target filename for the recording. If the UI is missing you may still be able to add recording options via the VM arguments field but that depends on your Eclipse flavor and plugins.

When Eclipse gives you a nice UI

• Turn on the recorder in the Flight Recorder tab.
• Choose a profile such as profile or tune custom events if you enjoy complexity.
• Pick a filename that does not conflict with your backup strategy or existing chaos.
• Launch your app with the configured run or debug button and watch the Eclipse console for recording messages.

When Eclipse refuses to cooperate

Not every Eclipse install is friendly. If there is no Flight Recorder tab you can still capture recordings from a running JVM with jcmd. That is often faster and more reliable than wrestling with the IDE.

Start the application and capture a recording

Use the launch button in Eclipse when you have configured JFR. The recorder starts according to your chosen settings and the JVM writes a recording file during the run. Keep an eye on the console for messages about start and stop events. If you are running long lived tests consider setting a duration so the recording does not eat your disk.

Save the file and open it for analysis

When the run finishes or when you stop the recorder open the generated .jfr file in the Eclipse JFR viewer or export it to analyze in other tools. Look for allocation hotspots method hotspots and wall time hotspots to guide optimization work. The viewer shows threads I O and CPU hotspots so you can prioritize the things that actually slow your app down.

Use jcmd as a reliable fallback

Find the JVM process id with jps or your OS process viewer. Then run a command like this from a terminal to start a recording from outside Eclipse

jcmd 1234 JFR.start name=MyRun settings=profile duration=60s filename=recording.jfr

To stop early run

jcmd 1234 JFR.stop name=MyRun

jcmd is especially useful for production or containerized JVMs where the IDE has no business being involved.

Troubleshooting and quick tips

• If you do not see a recording file check file permissions and the working directory of the JVM.
• Use profile for general profiling and switch to custom when you need very specific events or lower overhead.
• For short tests set a duration so you do not forget about the recorder and find a 10 GB file on disk.
• Remember to correlate JFR findings with wall time and allocation metrics before changing production code.

That covers checking environment compatibility configuring launch settings starting a recording saving the output and using jcmd as a fallback. Now go find your performance bottleneck and pretend you knew it all along.