What is thread confinement?

• Thread confinement – data is accessed by exactly one thread, eliminating the need for synchronization.
• Stack confinement – local variables and method parameters live on the thread's stack; guaranteed private by the language.
• ThreadLocal confinement – each thread gets its own copy via ThreadLocal; get() returns the current thread's copy.
• remove() – must be called in a finally block on pooled threads to prevent memory leaks.
• Discipline – confinement depends on never publishing the confined reference to another thread.

What is stack confinement?

Local variables live on the calling thread's own stack frame. No other thread can reach them. This is the simplest form of thread confinement and the one most often used without developers even thinking about it.

package com.bank.service;

import java.math.BigDecimal;

public class InterestCalculator {
    public BigDecimal calculateInterest(BigDecimal principal, BigDecimal rate) {
        BigDecimal interest = principal.multiply(rate);  // stack-confined
        return interest;  // safe, no synchronization needed
    }
}

The danger is letting a confined reference escape by storing it in a shared field or returning a mutable object that callers can share.

What is ThreadLocal confinement?

Each thread gets its own independent copy of the value. The classic use case is non-thread-safe objects like SimpleDateFormat.

package com.bank.format;

import java.text.SimpleDateFormat;
import java.util.Date;

public class StatementFormatter {
    private static final ThreadLocal<SimpleDateFormat> FMT =
        ThreadLocal.withInitial(() -> new SimpleDateFormat("yyyy-MM-dd"));

    public String formatDate(Date date) {
        return FMT.get().format(date);  // each thread uses its own formatter
    }
}

Why must you call remove() on pooled threads?

In a thread pool, worker threads are reused across tasks. A ThreadLocal value set by one task persists until the thread is destroyed or the value is explicitly removed. Without remove(), two problems occur: memory leaks (the value and its class loader are retained) and context bleed (task B sees task A's value).

// WRONG: leaks memory and context in a pool
private static final ThreadLocal<String> CONTEXT = new ThreadLocal<>();

public void processRequest(String correlationId) {
    CONTEXT.set(correlationId);
    process();
    // forgot to remove! Next task on this thread sees this correlationId
}

// CORRECT: always clean up
public void processRequest(String correlationId) {
    try {
        CONTEXT.set(correlationId);
        process();
    } finally {
        CONTEXT.remove();  // guaranteed cleanup
    }
}

How does confinement eliminate synchronization?

If data is never shared between threads, there can be no data race. No data race means no locks needed, no deadlocks possible, and no contention overhead. Confinement is the most efficient concurrency strategy because it has zero synchronization cost.

How does confinement relate to immutability?

Both confinement and immutability eliminate data races, but through different mechanisms. Confinement ensures only one thread accesses the data. Immutability ensures the data cannot be modified even if multiple threads access it. When possible, prefer immutability because it is simpler and compiler-verifiable (with final fields and records).

What are common mistakes?

Leaking a ThreadLocal value into a shared structure breaks confinement.

// WRONG: publishing a confined reference to a shared map
private static final Map<String, Object> shared = new ConcurrentHashMap<>();
private static final ThreadLocal<SimpleDateFormat> FMT =
    ThreadLocal.withInitial(() -> new SimpleDateFormat("yyyy-MM-dd"));

public void leakExample() {
    shared.put("formatter", FMT.get());  // BREAKS confinement!
    // Now two threads can access the same SimpleDateFormat
}

Another mistake is using ThreadLocal with virtual threads. Virtual threads can number in millions, and each gets its own ThreadLocal copy, causing excessive memory usage. Use ScopedValue (Java 21 preview) for virtual thread contexts.

What about arrays and collections in stack confinement?

Local arrays and collections are stack-confined as long as you do not publish them to shared state. Returning a local collection from a method is safe if the caller does not share it.

public List<BigDecimal> calculateDailyInterests(List<Account> accounts) {
    List<BigDecimal> results = new ArrayList<>();  // stack-confined
    for (Account a : accounts) {
        results.add(a.getBalance().multiply(dailyRate));
    }
    return results;  // ownership transfers to the caller
}

What should a senior engineer know?

• ThreadLocal internally uses a ThreadLocalMap stored inside each Thread object. The map uses weak references to the ThreadLocal key, but strong references to the value. This means if the ThreadLocal variable itself is garbage collected, the value remains until remove() is called or the thread dies.
• In web applications, the request thread sets up a ThreadLocal context (MDC, security principal, locale) at the start and removes it in a servlet filter's finally block.

What are common interview follow-up questions?

• Can you have stack confinement with arrays and collections? Yes, as long as references do not escape.
• What are scoped values and how do they improve on ThreadLocal? ScopedValues are immutable within a scope, automatically cleaned up, and cheaper for virtual threads.
• How does ThreadLocal interact with class loading? ThreadLocal values hold a strong reference to their class, which can prevent class loader garbage collection in application servers.