The Life Cycle of Java Objects: From Allocation to Old Generation

At 10 am, developer Zhao receives a new recommendation‑system requirement and begins aggressively creating objects with new in his IDE, prompting a dialogue with the garbage collector that humorously questions his behavior.

After deployment, the service’s response time spikes, leading Zhao to investigate performance metrics. Monitoring shows increased latency, and GC logs reveal frantic activity, prompting an emergency rollback and dump of GC logs for analysis.

The article then presents a simplified version of the user‑recommendation code (illustrated by an image) and explains that a real request loads various material types (machine‑learning, commercial, operational, exposure, relational, etc.) into memory.

Case 1 – Objects surviving 15 young GCs: Objects are initially allocated in Eden; when Eden fills, a Young GC moves surviving objects to Survivor 1. Subsequent allocations and Young GCs repeatedly shuffle survivors between Survivor spaces until, after 15 cycles, the remaining objects are promoted to the old generation.

Case 2 – Dynamic age‑based promotion: After a Young GC, if the total size of survivors exceeds 50 % of a Survivor space, the longest‑living objects (by GC count) are directly promoted to the old generation, exemplified by Context2 and Context3 moving to the old generation.

Case 3 – Space‑guarantee mechanism: With a 5 GB heap split equally between young and old generations (Eden = 2 GB, each Survivor = 250 MB), a traffic surge creates 500 KB per request. After a few seconds, Young GCs occur, but surviving objects (≈300 MB) cannot fit into Survivor spaces, triggering the space‑guarantee rule: if the old generation has enough free space, survivors are moved there; otherwise an Old GC runs, and if insufficient space remains, an OOM occurs.

A final diagram summarizes the entire object lifecycle across the three scenarios, illustrating allocation, survival, promotion, and potential OOM conditions.

In conclusion, the article demonstrates how Java objects traverse the JVM memory tiers in real production settings, encouraging readers to apply the described analysis to their own projects for performance tuning and reliability improvements.