Diagnosing Java Memory Leaks: JVM GC Roots, Monitoring with Spring Boot Actuator, Prometheus, Grafana, and MAT

Introduction – A memory leak occurs when dynamically allocated heap memory is not released, causing performance degradation or crashes. Although Java uses automatic garbage collection, leaks can still happen due to lingering references.

1. How the JVM identifies garbage objects – The JVM performs reachability analysis starting from GC Roots (e.g., stack variables, static fields, JNI references). Objects not reachable from any GC Root are considered garbage and reclaimed.

GC Roots include:

Objects referenced from the JVM stack.

Static fields in the method area.

Constant pool references.

JNI (native) references.

2. Analyzing symptoms and locating the problem – A production service showed intermittent time‑outs, high CPU load, and frequent full GC pauses. By examining logs and metrics (CPU, threads, JVM memory) collected via Spring Boot Actuator, Prometheus, and Grafana, the team identified typical leak patterns in the young and old generations.

Monitoring setup

Gradle dependencies:

compile 'org.springframework.boot:spring-boot-starter-actuator'
compile 'io.micrometer:micrometer-registry-prometheus'

YAML snippet to expose metrics:

management:
  endpoints:
    web:
      exposure:
        include: health,prometheus

Prometheus scrapes http://<ip>:<port>/actuator/prometheus, and Grafana visualizes the data.

Leak detection charts – Images show characteristic patterns in the Eden, Survivor, and Old generations, as well as Stop‑The‑World GC spikes, confirming a memory leak.

3. Locating the leaking code

Steps:

Find the process ID: ps -ef|grep projectName Dump the heap: jmap -dump:live,format=b,file=dump.hprof <pid> Analyze the dump with Eclipse MAT (Memory Analyzer Tool).

MAT reveals a chain of references ending at StaticLoggerBinder, a singleton held by the logger framework. Each request creates a ListAppender that is added to a COWArrayList inside AppenderAttachableImpl, causing the list to grow until the old generation fills, triggering frequent full GCs.

Relevant code excerpts:

// Logger creation
Logger logger = org.slf4j.LoggerFactory.getLogger(cronBean.getClass());
// Temporary ListAppender
ListAppender<ILoggingEvent> listAppender = new ListAppender<>();
((ch.qos.logback.classic.Logger)logger).addAppender(listAppender);
listAppender.start();

Fix – Ensure the ListAppender is removed in a finally block:

try {
    // business logic
} finally {
    ((ch.qos.logback.classic.Logger) logger).detachAppender(listAppender);
    MDC.remove("tid");
}

Conclusion

Understanding GC fundamentals is essential; changing collectors won’t solve leaks caused by code.

Effective monitoring (Grafana, Prometheus, Actuator) and analysis tools (MAT, Arthas) accelerate diagnosis.

Data‑driven investigation prevents mis‑diagnosis and reduces time to resolution.

Additional resources: Dynatrace ebook on garbage collection and various monitoring tools.