Diagnosing and Resolving Excessive Java Memory Usage in Spring Boot Services

In a production environment the author observed several Spring Boot services each using nearly 12 GB of memory on a 64 GB server, causing the applications to become unresponsive after traffic spikes.

Background : The high memory consumption was reproduced locally by simulating the production load, revealing that the JVM default heap size was set far larger than necessary.

Investigation steps :

Step 1: Use jps (or top ) to list Java process IDs.

Step 2: Run jmap -heap <pid> to view the maximum heap size (e.g., 4 GB) and other memory regions.

The -Xmx (maximum heap) is typically one‑quarter of physical memory, while -Xms (initial heap) defaults to one‑sixty‑fourth. On a 64 GB machine the defaults can allocate up to 12 GB per JVM, which quickly exhausts resources when multiple services run.

Default JVM heap rules (Oracle) :

If physical memory ≤ 192 MB, max heap = ½ × memory.

If physical memory ≤ 1 GB, max heap = ¼ × memory.

For larger machines the defaults increase (e.g., 1 GB max heap on 32‑bit JVMs with ≥ 4 GB RAM, up to 32 GB on 64‑bit JVMs with ≥ 128 GB RAM).

Because the production services were started without explicit JVM options, they inherited these defaults, leading to excessive RAM usage.

Remediation :

Explicitly set appropriate -Xms and -Xmx values based on the service’s actual workload.

Monitor heap, non‑heap, and GC activity with tools such as VisualVM or MAT.

Adjust GC settings if necessary and consider profiling to detect memory leaks or large object allocations.

By configuring JVM parameters to match the server’s capacity and the application’s needs, memory consumption can be reduced dramatically, improving stability and performance.