What is InheritableThreadLocal?

• InheritableThreadLocal – subclass of ThreadLocal whose value is copied from parent to child at new Thread().
• Timing – inheritance is a one-time copy in the Thread constructor, not at task submission.
• Pool danger – pool workers are created once by the pool creator; they inherit the creator's value, not the submitter's.
• Staleness – tasks see the creator's context, not the current request's context.
• Leakage – a value set by one task leaks to the next task on the same reused worker.
• Fix – capture on the submitting thread, set on the worker, and always remove() in a finally block.

How does InheritableThreadLocal work?

When a new Thread is created via new Thread(), the constructor copies the parent thread's InheritableThreadLocal values to the child thread. This is a one-time copy that happens at thread creation, not at task submission.

package com.bank.context;

public class InheritableDemo {
    private static final InheritableThreadLocal<String> ctx = new InheritableThreadLocal<>();

    public static void main(String[] args) throws InterruptedException {
        ctx.set("REQ-123");
        Thread child = new Thread(() -> System.out.println(ctx.get()));
        child.start();
        child.join();
        // prints REQ-123: child inherited parent's value at creation
    }
}

How do you override childValue for defensive copying?

The childValue(T) method is called during thread creation to transform the parent's value. Override it to create a defensive copy so the child gets its own instance.

package com.bank.context;

import java.util.ArrayList;
import java.util.List;

public class DefensiveCopyDemo {
    private static final InheritableThreadLocal<List<String>> tags =
        new InheritableThreadLocal<>() {
            @Override
            protected List<String> childValue(List<String> parentValue) {
                return new ArrayList<>(parentValue);  // defensive copy
                // Without this, parent and child share the same list
            }
        };
}

Why is it dangerous in thread pools?

Inheritance happens in the Thread constructor, not when a task is submitted. Pool workers are created once during pool initialization. They inherit the pool creator's values, not the task submitter's values.

package com.bank.context;

import java.util.concurrent.*;

public class PoolDangerDemo {
    private static final InheritableThreadLocal<String> user = new InheritableThreadLocal<>();

    public static void main(String[] args) {
        user.set("admin");  // whoever built the pool
        ExecutorService pool = Executors.newFixedThreadPool(2);
        // Workers created here inherit "admin"

        user.set("rajesh");  // request thread sets context
        pool.submit(() -> {
            System.out.println(user.get());  // prints "admin" (STALE!)
            // Rajesh's context was never propagated to the worker
        });

        user.set("priya");  // another request
        pool.submit(() -> {
            System.out.println(user.get());  // still prints "admin" (STALE!)
        });
    }
}

What is the correct pattern for pools?

Capture the context on the submitting thread, set it explicitly on the worker, and always remove it in a finally block to prevent leakage to the next task.

package com.bank.context;

import java.util.concurrent.ExecutorService;

public class ExplicitPropagation {
    private static final ThreadLocal<String> user = new ThreadLocal<>();

    public static void submitWork(ExecutorService pool, Runnable task) {
        String current = user.get();  // capture on submitting thread
        pool.submit(() -> {
            user.set(current);         // set explicitly on the worker
            try {
                task.run();
            } finally {
                user.remove();         // ALWAYS clear to prevent leakage
            }
        });
    }
}

How does Spring's TaskDecorator automate this?

Spring provides a TaskDecorator interface that wraps every task submitted to a ThreadPoolTaskExecutor. This is the production approach for propagating request context (MDC, security context, correlation ID) across thread boundaries.

package com.bank.config;

import org.slf4j.MDC;
import org.springframework.core.task.TaskDecorator;
import java.util.Map;

public class MdcTaskDecorator implements TaskDecorator {
    @Override
    public Runnable decorate(Runnable runnable) {
        Map<String, String> contextMap = MDC.getCopyOfContextMap();
        return () -> {
            if (contextMap != null) MDC.setContextMap(contextMap);
            try {
                runnable.run();
            } finally {
                MDC.clear();  // always clean up
            }
        };
    }
}

What are the two failure modes?

| Failure | Cause | Impact |
|---------|-------|--------|
| Staleness | Task sees the pool creator's value, not the submitter's | Wrong user context, wrong correlation ID |
| Leakage | A value left by one task bleeds into the next task on the same worker | Security vulnerability: user A sees user B's data |

Both failures are silent: no exception, no log, just incorrect behavior.

What are modern alternatives?

Java 21 introduced ScopedValue as a preview feature. ScopedValues are inherently bound to a scope and cannot leak. The Micrometer context-propagation library provides automatic propagation across reactive and async boundaries.

What are common interview follow-up questions?

• How do scoped values in modern Java improve on InheritableThreadLocal? Scoped values are immutable within a scope and automatically cleaned up when the scope ends.
• How does Spring's TaskDecorator propagate context across pools? It wraps each submitted task with capture-and-restore logic.
• What is the Micrometer context-propagation library? A library that hooks into reactive frameworks (Project Reactor, RxJava) to propagate ThreadLocal values across async boundaries.