Transmit thread local values by inheritable thread local is a potential leaking problem. A new created thread can never know how to deal with the inherited values. The transmittable thread local values should be created and cleared within a task's lifecycle. InheritableThreadLocal will leak the management of transmittable thread local values out of a task.

Here are some thoughts about the inheritable feature:

case 1

Inheritable feature in thread pooling components(ThreadPoolExecutor etc.) should never happen, because threads in thread pooling components is pre-created and pooled, so these threads is neutral for biz logic/data.

case 2

Whether the value should be inheritable or not can be controlled by the data owner, disable it carefully when data owner have a clear idea.

disable inheritable by overriding the childValue and return initialValue():

TransmittableThreadLocal<String> transmittableThreadLocal = new TransmittableThreadLocal<String>() {
     protected String childValue(String parentValue) {
         return initialValue();
     }
 }

Solved.

为什么不直接 继承 ThreadLocal 呢？
我理解的 TTL 和 ITL 是解决不同场景的方案，从出发点就不一样。

或者可以在 构造器 增加参数-inheritable，默认为 false

@youzipi

为什么不直接 继承 ThreadLocal 呢？

在业务中可以直接以new Thread这样的方式 来 使用，正确完成传递 是 期望的功能。
# 虽然，有了线程池，直接new线程的做法，极有可能是不应该的（不是最佳实践！）。

选择继承ITL而不直接继承ThreadLocal，原因如下：

• 在new Thread的情况下，也能进行传递。即包含上面new Thread的传递功能。
• 继承ThreadLocal，对于使用了ITL的业务代码，则不方便切成TTL了。

而 inheritable 在业务上 有潜在的（potential）的 泄漏或污染。
这样的情况下，期望进一步方便地解决好～

我理解的 TTL 和 ITL 是解决不同场景的方案，从出发点就不一样。

要说明/解决问题，你需要给出 全场景 下的说明，比如说明出：
当TTL/ITL在继承上下文有泄漏或污染问题时，应该全部使用成ThreadLocal 且 对应的业务功能 也都能解决好。

那么，就可以推出你的结论：『 TTL和ITL是解决不同场景的方案，从出发点就不一样』。