Why System.out.println Slows Java by 10×: Object Allocation & TLAB Explained

Performance Test Code

import com.google.common.base.Stopwatch;
import java.util.concurrent.TimeUnit;
public class StackTest {
    public static void main(String[] args) {
        Stopwatch started = new Stopwatch();
        started.start();
        User user = null;
        for (long i = 0; i < 1000_000_000; i++) {
            user = new User();
        }
        started.stop();
        System.out.println(started.elapsed(TimeUnit.MILLISECONDS) + "ms");
        // without printing ~300ms, with printing ~3000ms
        // System.out.println(user);
    }
}

class User {
    private int age;
    private String userName;
    public int getAge() { return age; }
    public void setAge(int age) { this.age = age; }
    public String getUserName() { return userName; }
    public void setUserName(String userName) { this.userName = userName; }
}

The test creates one billion User objects; without the System.out.println(user) call the runtime is about 300 ms, but adding the print statement inflates it to roughly 3000 ms, a ten‑fold slowdown that varies with hardware.

Although System.out.println holds a lock, the key issue here is object escape: printing forces the User instance to escape the method, preventing stack allocation.

Object Allocation Rules

Java’s JVM follows several allocation strategies, illustrated in the diagram below.

Stack Allocation

Stack allocation places thread‑private objects directly on the stack, allowing instant reclamation without garbage collection. It requires:

Small object size (large objects cannot be stack‑allocated).

No escape of the object (enable with -XX:+DoEscapeAnalysis).

Possibility of scalar replacement ( -XX:+EliminateAllocations).

In the demo, the User object could be replaced by its two fields ( age and userName) if it remained on the stack.

TLAB Allocation

TLAB (Thread‑Local Allocation Buffer) is a per‑thread region inside the Eden space. When enabled (default), each thread gets its own TLAB to reduce contention during heap allocation.

Allocation Strategy

If a TLAB of 100 KB has 80 KB used and a 30 KB request arrives, the JVM may either discard the current TLAB and request a new one, or allocate the object directly on the heap while keeping the partially used TLAB for smaller future allocations. The decision is based on an internal refill_waste threshold, which the VM adjusts at runtime for optimal performance.

JVM Parameter Explanation

-XX:+UseTLAB

– Enable TLAB (default). -XX:TLABRefillWasteFraction – Ratio of TLAB space allowed to be wasted; default is 64 (1/64 of TLAB size). -XX:-ResizeTLAB – Disable automatic resizing of TLAB. -XX:TLABSize – Specify TLAB size in bytes.

Demo Analysis

The print statement causes the User object to escape, breaking the conditions for stack allocation. Consequently, the JVM falls back to heap allocation, triggering frequent garbage collections and a dramatic performance drop. Disabling TLAB with -XX:+UseTLAB would further reduce allocation speed, especially under multithreaded contention.