Why Does TraceId Get Mixed Up Under High Concurrency Even Though the Parent Thread Passes It to Child Threads?

In microservice development, full‑stack tracing requires passing a TraceId from the gateway down to the database, often across asynchronous threads. The JDK class InheritableThreadLocal (ITL) can automatically copy parent thread locals to a newly created child thread.

Why ITL Fails

ITL only copies values during the new Thread() creation in the thread's init() method. When code uses a ThreadPoolExecutor, threads are reused instead of being newly created, so the copy never occurs for reused workers.

Scenario:

Request A is submitted; a new worker Thread‑1 is created, ITL copies A's TraceId, and the task runs correctly.

Thread‑1 finishes and returns to the pool.

Request B arrives; the pool reuses Thread‑1, which still holds A's TraceId because no new new Thread() call triggers ITL. Consequently, logs for B show A's TraceId, causing a "trace mixing" issue.

During low‑traffic periods, idle threads are destroyed (keepAliveTime expires) and new threads are created for new requests, so the problem is not observed. Under high concurrency, threads are constantly reused, propagating stale context thousands of times.

Manual Context Propagation

The simplest fix is to pass the TraceId explicitly:

// 1. Capture TraceId in the submitting thread
String traceId = TraceContext.getTraceId();
executorService.submit(() -> {
    try {
        // 2. Set TraceId in the worker thread
        TraceContext.setTraceId(traceId);
        // business logic...
    } finally {
        // 3. Clean up to avoid leakage
        TraceContext.remove();
    }
});

This guarantees correct tracing but is highly invasive; every place that submits a task must repeat the try‑finally block, and forgetting the cleanup reintroduces contamination.

Using Alibaba TransmittableThreadLocal (TTL)

TTL is a widely adopted open‑source solution that solves ITL's thread‑pool limitation. It provides TtlRunnable.get() to wrap a Runnable so that the context is automatically transmitted.

// Set context in the main thread
UserContextHolder.set(userInfo);
// Wrap the task
Runnable ttlRunnable = TtlRunnable.get(() -> {
    Map<String, Object> user = UserContextHolder.get();
    // business logic...
});
executorService.execute(ttlRunnable);

TTL can also wrap an entire ExecutorService:

ExecutorService normalPool = Executors.newFixedThreadPool(5);
ExecutorService ttlPool = TtlExecutors.getTtlExecutorService(normalPool);
// Use ttlPool for all submissions; no manual wrapping needed

TTL works by capturing the parent thread's context at submit(), replaying it on the worker thread before run(), and cleaning up after execution, effectively moving the context lifecycle from "thread‑bound" to "task‑bound".

Conclusion

When a system uses thread pools, context propagation is unavoidable and must be handled carefully. Relying on thread reuse without proper propagation leads to trace contamination, especially under high concurrency. Either manually transmit the context or adopt TTL to automate safe transmission.