Java Object Allocation

Java objects are normally created in heap memory, with HotSpot commonly using thread-local allocation buffers (TLABs) to make allocation fast. The allocated object remains managed by the garbage collector until it becomes unreachable and is reclaimed.

When Java code executes `new`, the JVM must obtain memory for the object and initialize it. For ordinary objects, that memory comes from the Java heap, while the reference to the object may be stored in a local variable, field, or another object.

In HotSpot, a thread commonly allocates small objects from its own thread-local allocation buffer, or TLAB. A TLAB is a portion of heap memory reserved for one thread, allowing many allocations to proceed by quickly advancing a pointer without synchronizing with other application threads.

If a thread cannot satisfy an allocation from its TLAB, the JVM can obtain more heap space, potentially acquiring another TLAB or allocating through a shared allocation path. Large or otherwise special allocations can follow different paths depending on the JVM and garbage collector configuration.

Allocation is separate from garbage collection. Creating an object makes it eligible for management by the garbage collector, but collection does not normally happen immediately after each allocation. An object can be reclaimed after it is no longer reachable according to the garbage collector's reachability rules.

Object allocation is therefore usually cheap compared with manually managing heap memory, but allocation rate still matters. High rates of temporary-object creation can increase GC activity and memory pressure, so performance analysis should consider both allocation behavior and garbage-collection behavior.

Key points

• Most ordinary Java objects are allocated on the heap.
• HotSpot commonly uses TLABs to make thread-local object allocation fast.
• A TLAB is heap space reserved for a particular application thread.
• An allocation that cannot fit in the current TLAB can use another allocation path.
• Object allocation and garbage collection are separate operations.
• High allocation rates can increase memory pressure and GC work.

Interview questions

Where are Java objects allocated?

Ordinary Java objects are generally allocated in the heap. The Java language does not expose the exact physical allocation mechanism, and the JVM can optimize object handling in some circumstances. In HotSpot, TLABs are commonly used to make heap allocation efficient. The object itself and the reference that points to it should be distinguished conceptually.

What is a TLAB and why does it improve allocation performance?

A TLAB is a region of heap memory assigned to an individual application thread. The thread can usually allocate objects within that region by advancing an allocation pointer. This reduces contention because common allocations do not need to coordinate with other threads for every object. When the TLAB lacks sufficient space, the JVM can obtain additional space through another allocation path.

Does `new` immediately cause garbage collection later?

No. `new` requests storage and initializes an object, but it does not imply that garbage collection will happen for that object immediately. The object becomes eligible for reclamation when it is no longer reachable, and the collector decides when and how to reclaim its storage. Allocation and collection are separate JVM activities.

What happens when a thread's TLAB runs out of space?

The thread cannot continue allocating from that TLAB once there is insufficient contiguous space for the requested object. The JVM can obtain a new TLAB or use an alternative allocation path. The exact behavior depends on the JVM and garbage collector configuration. This is one reason TLABs should be understood as an optimization rather than a Java-language guarantee.

How would you investigate excessive object allocation in a Java service?

I would first establish whether allocation rate and GC activity are actually contributing to the observed problem. I would use profiling or JVM telemetry to identify allocation-heavy code paths and inspect object lifetimes rather than assuming that every allocation is harmful. Then I would determine whether reducing temporary objects, changing data structures, or adjusting application behavior addresses the measured bottleneck. JVM configuration changes should come after understanding the workload and collecting evidence.