Why Did My Spring Boot Services Consume 12 GB Each? A JVM Memory Deep Dive

Background

After the system went live it ran smoothly at first, but as traffic grew the production environment showed that each Spring Boot microservice was using nearly 12 GB of memory on a server with 64 GB total, causing the services to become unresponsive.

Because no screenshots were taken in production, the author reproduced a similar situation locally and captured memory usage graphs.

The memory was almost fully utilized, prompting an investigation into why the Java processes were consuming so much RAM.

Solution Steps

step1: Use jps or top to find the process ID.

step2: Run jmap -heap <PID> to view heap configuration.

The output shows a maximum heap size of 4 GB, while the production servers allowed up to 12 GB per Spring Boot instance.

Maximum heap size (‑Xmx) is usually about one‑quarter of physical memory.

Initial heap size (‑Xms) is typically one‑sixty‑fourth of physical memory.

According to Oracle, the default maximum heap size is half of physical memory for small machines (≤ 192 MB) and one‑quarter for larger machines (≤ 1 GB). The initial heap size is at least 8 MB or 1/64 of physical memory, whichever is larger.

On servers, the defaults can be higher: up to 1 GB on 32‑bit JVMs with ≥ 4 GB RAM, and up to 32 GB on 64‑bit JVMs with ≥ 128 GB RAM.

The root cause was that the production deployment used the default JVM parameters, leading each Java process to allocate an excessively large heap.

Post‑mortem

Typical investigation steps for high memory usage:

Check JVM parameters; if defaults are used, adjust them according to application needs and server capacity.

Monitor memory usage with OS tools or APM solutions, observing heap, non‑heap, and GC behavior.

Analyze GC logs to understand collection frequency and pause times.

Set appropriate heap sizes to avoid over‑allocation.

Use memory‑analysis tools such as VisualVM or MAT to detect leaks or large objects.

Running Spring Boot without explicit JVM settings can cause:

Inappropriate defaults that lead to out‑of‑memory errors, frequent GC, and performance degradation.

Wasted server resources because the JVM allocates heap based on physical memory rather than actual workload.

Therefore, it is recommended to configure JVM options deliberately in production to improve performance, stability, and resource efficiency.