Why Does Your JVM Keep Objects Alive After Method Returns? A Memory & GC Deep Dive

Preface

When I first received this requirement, I was excited because it matched my expertise: writing a bug.

The goal is to make low‑load servers consume extra memory and CPU so their load appears higher.

JVM Memory Allocation Review

I quickly wrote the following code:

I wondered whether the mem object would be reclaimed immediately after the method finishes. Some people think it is.

I investigated and found that many indeed assume immediate reclamation.

To verify, I ran an experiment.

I started the application with the following JVM parameters:

This allowed me to connect via JMX and monitor memory and GC.

If the mem object were reclaimed after the method, allocating 250M would produce a clear memory spike and trigger GC.

The memory curve indeed rose but did not drop immediately; GC remained idle.

Using jstat showed the same result.

Both YGC and FGC were absent; only Eden usage increased due to the 250M allocation.

When I allocated a third 250M block, Eden reached 98.83% and a YGC occurred, freeing memory.

The key takeaway: objects are reclaimed only when a GC occurs, regardless of being local or global.

When Eden space is insufficient, a YGC triggers reclamation of the mem object.

If the object is a local variable, it becomes unreachable after the method, and the GC will collect it during the next collection cycle.

Large objects bypass Eden and are allocated directly to the old generation.

Prefer Allocating Objects in Eden

Objects are first placed in the young generation’s Eden area, provided they are not too large.

Large Objects Go Directly to Old Generation

When an object is too big, it is allocated to the old generation.

Allocating 1000M caused the allocation to go straight to the old generation.

Linux Memory Observation

Before starting the app, the server used about 3G of memory.

After launching, it consumed roughly 600M.

To meet the requirement, I allocated memory carefully: small objects in the young generation to keep it around 90% full, and large objects in the old generation to also stay near 90% usage, avoiding frequent GC.

Allocated ~800M of small objects to fill the young generation.

Allocated ~1638M in the old generation (60% of remaining space).

No GC occurred during this process, and total memory usage reached about 3.5G.

Conclusion

Controlling JVM memory allocation is not trivial; it requires understanding of heap layout and garbage collection. This experiment deepened my insight, and I hope it helps others.