Why Adding More JVM Memory Won’t Fix Performance: Real Tuning Strategies

Preface

When people talk about JVM tuning, they often joke that “just increase memory”. The article questions whether simply adding memory improves performance.

Memory Tuning in High‑Concurrency Scenarios

In a flash‑sale scenario each order creates about 0.2 MB of objects, generating 100 MB per second. After one second those objects become garbage.

Unoptimized Situation

Assume a 3 GB JVM with default generation sizes. Objects are allocated in Eden, then moved to Survivor, and eventually to Old when they survive several GCs.

With an 800 MB young generation, a YGC is triggered every 8 seconds. If 100 MB of objects survive, they are copied to Survivor, which may overflow and promote directly to Old.

Consequently, every 8 seconds about 100 MB moves to Old; the 2 GB Old space fills in roughly two minutes, triggering a Full GC that is costly.

Solution 1: Blindly Increase Heap Size

Doubling the heap (e.g., expanding Young to 2.4 GB) reduces Full GCs but lengthens YGC pause time because larger Young spaces take longer to scan and copy.

Thus, simply adding memory can worsen latency.

Solution 2: Enlarge Young Generation, Keep Old Reasonable

For high‑concurrency workloads, increase Eden and Survivor sizes while keeping Old space sufficient. This reduces YGC frequency and allows more objects to survive in Survivor, delaying promotion to Old and avoiding frequent Full GCs.

With a larger Eden, YGC occurs less often, and a larger Survivor lets more objects survive a single GC cycle.

Other Practical Tips

Reduce JVM Stack Size

Each thread’s stack defaults to 1 MB; lowering it can save memory under heavy concurrency.

Increase GC Worker Threads

If using a parallel collector, raise the number of GC threads.

Inspect Heap Information

jmap -heap [pid]

Identify Heap Consumers

jmap -histo [pid] | head -20

Monitor GC Statistics

jstat -gc [pid] [interval‑ms] [count]