Spring Boot Actuator exposes several JVM memory–related metrics (for example,/actuator/metrics/jvm.memory.used) that provide visibility into heap, non-heap, and off-heap memory usage as well as Garbage Collection (GC) activity of a Java application.
This article explains some of the most important JVM metrics available via Actuator and what each metric represents.
Spring Boot applications with Spring Boot Actuator
VMware Tanzu Application Service (TAS) / Elastic Application Runtime
jvm.memory.usedEndpoint
Description
Returns the current amount of memory in use, in bytes.
This metric is tagged, allowing it to be filtered by memory area and memory pool.
area: heap | nonheap
id: specific memory pool (for example, Eden Space, Tenured Gen, Metaspace)
/actuator/metrics/jvm.memory.used?tag=area:heap
Represents all heap usage combined, across:
Eden Space
Survivor Space
Tenured (Old) Generation
This value fluctuates depending on GC activity.
Short-lived object allocation area
High fluctuation is expected
Frequent growth does not indicate a memory leak
Objects that survived at least one GC
Usually small
Helps explain object aging behavior
Most important metric for leak detection
Represents long-lived objects
If this value steadily increases over time after full GCs, it may indicate a heap leak
If stable, heap is healthy
Includes:
Metaspace
Compressed Class Space
Code Cache
This memory does not belong to the Java heap but is still part of the JVM process RSS.
Stores:
Class metadata
Reflection data
Dynamic proxies
Steady growth may indicate:
Ongoing class loading
Classloader retention
Dynamic bytecode generation
Holds compressed class pointers
Typically stable
Grows with number of loaded classes
Stores JIT-compiled native machine code.
Gradual growth is normal during JVM warm-up
May increase over long uptimes
Rarely a leak unless it grows without bound
Memory currently reserved by the JVM
Often equals -Xmx once the heap is fully expanded
Maximum heap size
Typically equal to -Xmx
Fixed unless JVM is restarted
Provides:
COUNT: number of GC pauses
TOTAL_TIME: total time spent in GC
MAX: longest pause observed
Useful for:
Correlating GC behavior with memory pressure
Verifying GC health (many short pauses are usually fine)
Reports usage of:
Direct buffers
Mapped buffers
Usually small unless application uses:
Netty
NIO direct buffers
Memory-mapped files