Using NetBeans’ Built‑In Java Profiler to Detect Memory Leaks

Goal: Spot and Fix Memory Leaks with NetBeans Profiler

When a Java application keeps allocating objects that are never released, it can exhaust the heap and crash. NetBeans offers a visual profiler that lets you see live memory usage, generate allocation snapshots, and trace the exact classes responsible for leaks. This guide walks you through enabling the profiler, configuring it for low overhead, and interpreting the results so you can make a data‑driven fix.

Prerequisites

• NetBeans IDE 17 or newer (older releases may lack the latest profiler UI).
• A compatible JDK (Java 11+). The JDK used to run the application must match the JDK bundled with NetBeans; otherwise the profiler may fail.
• Project built with mvn clean install or gradle build so that NetBeans can launch it.
• Administrator or developer privileges to adjust JVM options if needed.

Step‑by‑Step Procedure

1. Open the Profiler Tab

From the IDE menu, select Run > Profile > Java Application. NetBeans will build the project and launch it in a new JVM with profiling enabled. The Profiler tab appears at the bottom of the IDE, showing live CPU, memory, and thread charts.

2. Choose a Profiling Mode

The profiler offers two modes:

• Sampling – the profiler takes periodic snapshots of the call stack. It has low overhead (≈2–5% slowdown) but may miss short‑lived objects.
• Instrumentation – the JVM is byte‑code instrumented to record every allocation. Accuracy is higher, but performance can drop by 30–50%.

To switch modes, click the Mode drop‑down in the toolbar and select the desired option. For memory‑leak detection, start with Sampling to keep the application responsive, then switch to Instrumentation for a deeper dive once you’ve narrowed the suspect area.

3. Generate a Memory Snapshot

While the application runs, click the Take Snapshot button (camera icon) in the memory pane. The profiler captures the current heap state, listing objects by class, count, and retained size.

4. Inspect Allocation Traces

Open the Allocation Traces tab. Here each line shows a call stack that led to an allocation. Use the filter box to search for the suspect class or package. The trace’s Count and Size columns reveal whether the class is a likely leak source.

5. Narrow Down the Leak

Apply the following tactics:

• Filter by Package – limit the view to the application’s own packages.
• Sort by Retained Size – the highest values often indicate leaking objects.
• Compare Snapshots – take a second snapshot after a period of activity; objects that persist between snapshots are candidates.

6. Validate the Leak

To confirm that a class is leaking, add a simple test harness that repeatedly creates objects of that class without releasing references. If the profiler shows a steady increase in object count and retained size, you’ve identified a leak.

Concrete Example

Suppose you have a static list that grows unboundedly:

public class LeakDemo {
    private static final List<String> data = new ArrayList<>();

    public static void add(String s) {
        data.add(s);
    }
}

Run the application with the profiler in sampling mode, then call LeakDemo.add("test") in a loop. After a minute, take a snapshot. The memory tab will show ArrayList and String objects with high counts. In the allocation trace, the stack will point to LeakDemo.add as the allocation site, confirming the leak.

Expected Checks

• The Profiler tab should open automatically after selecting Profile.
• Memory charts should update in real time; if they remain static, check that the application is running in the IDE’s profiler JVM.
• Snapshots should list at least one class with a non‑zero Retained Size that grows over successive snapshots.
• Switching to Instrumentation should not crash the IDE; if it does, reduce the JVM heap or disable other profilers.

Recovery Options

• If the profiler slows the application too much, switch back to Sampling or reduce the heap size via -Xmx in the Run > Profile > Java Application > VM Options dialog.
• To stop profiling, press the Stop button in the toolbar. The JVM will terminate, freeing memory.
• If the profiler UI becomes sluggish, close all other tabs and consider profiling a smaller module or a single class.

Limitations and Practical Checks

NetBeans’ profiler is a powerful tool, but it has constraints:

• Instrumentation mode can add 30–50% overhead; avoid using it for production‑like loads.
• Large heaps (>2 GB) may cause the UI to freeze; filter views or split the profiling session.
• Some JDKs (e.g., early Java 16 builds) may not support full allocation tracing; ensure you’re on a stable release.

To verify the profiler’s accuracy, run a known leak test: a class that creates an array of objects and never clears it. The profiler should show a steady increase in object count and size. If it doesn’t, double‑check the JDK version and that you’re profiling the correct process.

Conclusion

By integrating the NetBeans profiler into your development workflow, you can quickly identify memory leaks, understand their root causes, and apply precise fixes. Start with sampling to keep the UI responsive, then drill down with instrumentation and snapshots. The visual feedback—charts, tables, and allocation traces—transforms guessing into evidence, saving time and preventing production outages.