Capturing and comparing MBean states with JProfiler
MBeans expose a wide range of runtime metrics and management operations that are essential for understanding the internal state of Java applications. Traditionally, JProfiler has supported live inspection of MBeans during a profiling session.
With the new MBean snapshot feature in JProfiler 15, it is now possible to capture the complete MBean state, compare snapshots, and analyze metrics offline, even after the application has shut down.
This screencast demonstrates the new functionality with a small Hazelcast application that performs random map operations and registers a custom MBean for triggering cleanup operations.
Along the way, you will see how to:
- Capture and compare MBean snapshots manually
- Trigger MBean snapshots programmatically with method triggers
- Restrict the snapshot scope to specific MBeans
Advanced SSH remote profiling with JProfiler
Remote profiling can be challenging when SSH access involves custom setups, proxies, or cloud authentication plugins. JProfiler 15 introduces advanced SSH connection features that remove these obstacles, enabling profiling in complex environments without manual setup.
This screen cast shows how to profile remote JVMs even in situations where the built-in SSH client is insufficient, using AWS Session Manager as an example.
Along the way, you will see how to:
- Use OpenSSH mode for remote profiling
- Connect with ProxyCommand and the AWS CLI
- Handle SSH port forwarding restrictions with netcat mode
Profiling Java applications in VS Code with JProfiler
JProfiler now integrates directly into VS Code, bringing the powerful profiling tool into your everyday development workflow.
In this screencast, we profile the Spring Pet Clinic demo and walk through the features of the JProfiler extension for VS Code, including:
- Toggling profiling mode
- Automatic setup of profiled packages
- Source code navigation from profiling views
- Attach mode for unsupported launch methods (like Maven)
- Built-in Gradle integration
If you're using a launch method in VS Code that isn't currently supported, let us know — we’re always looking to expand support.
Advanced Kafka probe configuration in JProfiler
In our first Kafka screencast, we looked at how JProfiler correlates message flow and CPU usage through producers, consumers, and topic-level call trees.
In this follow-up, we go deeper, showing how to configure custom naming for Kafka messages based on their content.
This enables you to:
- split call trees by semantic message types
- track specific event types in probe views
- add value-level details to single event descriptions
- visualize outliers in event duration histograms
We also trigger a Kafka message spike via an API call and analyze its impact, all without changing the application code.
Profiling Kafka #1 – Message Flow & Hot Spots
Kafka-based applications are notoriously hard to profile. Message flow happens in background threads, stack traces don’t reveal the full picture, and it’s hard to know which topic contributes to which hot spot.
JProfiler’s Kafka probes give you deep insight—producers, consumers, and message-level details are all captured and correlated with performance data.
This screencast walks through profiling a Spring Kafka application, showing how:
- consumer call trees are split by topic
- producers link directly into probe views
- you can correlate CPU hot spots with Kafka topics
- Kafka events are filterable, inspectable, and aggregatable
Bringing JProfiler to VS Code with Kotlin Multi-Platform
At ej-technologies, we've long provided JProfiler integrations for Java IDEs like IntelliJ, Eclipse, and NetBeans. These plugins share a significant amount of logic—profiler configuration, session management, and communication with the JProfiler backend—all written in Kotlin.
When we decided to add support for VS Code, we faced a problem: VS Code extensions run on Node.js, not the JVM. Rewriting the plugin from scratch in TypeScript would have been inefficient. Instead, we turned to Kotlin Multi-Platform (KMP), allowing us to reuse our existing Kotlin code while adapting to the JavaScript ecosystem.
Refreshed JProfiler IDEA plugin for the new UI
Kotlin 2.0 features a total rewrite of the Kotlin compiler known as "Kotlin K2". IntelliJ IDEA will remove support for the old compiler in version 2024.3 impacting all plugins that depend on the Kotlin plugin, such as the JProfiler IDEA plugin.
The newest version of the JProfiler IDEA plugin for IntelliJ IDEA now includes support for Kotlin K2 mode. This means that the JProfiler plugin no longer prevents switching to K2 mode in IntelliJ IDEA 2024.2 and is now ready for IntelliJ IDEA 2024.3 where K2 mode will be the default and plugins depending on the old API will no longer be loaded.
We took this opportunity to align the JProfiler plugin with another recent major change in IntelliJ IDEA: The new UI, which became the default in IntelliJ IDEA 2024.2. It is impractical for IDEA plugins to support both the old and the new UI, so we decided to change the UI once the new UI became widely used.
Why JVMTI sampling is better than async sampling on modern JVMs
In recent years, "async sampling" has been hyped as a better way of CPU profiling on the JVM. While this has been true for some time, it is no longer the case. This blog post explains the history of sampling and the current state of the art.
Garbage collector analysis in JProfiler
This screencast shows how to use the garbage collector probe in JProfiler. Having access to detailed information about the overall activity of the GC, as well as the single garbage collections, is crucial for tuning the garbage collector and achieving an optimal performance for your application.
Recording JFR snapshots with JProfiler
Recording JFR snapshots with JProfiler
This screencast shows JProfiler's versatile functionality as a JFR recording controller. As an example, a JFR recording on a Kubernetes cluster is recorded and the resulting snapshot is shown in JProfiler. In this context, you can see the wizard for configuring JFR recording settings. In addition, JFR recordings of terminated JVMs and the handling of externally started JFR recordings are demonstrated.