在ThreadLocal的需求场景即是TTL的潜在需求场景，如果你的业务需要『在使用线程池等会缓存线程的组件情况下传递ThreadLocal』则是TTL目标场景。
下面是几个典型场景例子。
关于『分布式跟踪系统』可以了解一下Google的Dapper（介绍的论文：中文| 英文）。分布式跟踪系统作为基础设施，不会限制『使用线程池等会缓存线程的组件』，并期望对业务逻辑尽可能的透明。
分布式跟踪系统的实现的示意Demo参见DistributedTracerUseDemo.java
PS： 多谢 @wyzssw 对分布式追踪系统场景说明交流和实现上讨论建议：
举个具体的业务场景，在App Engine（PAAS）上会运行由应用提供商提供的应用（SAAS模式）。多个SAAS用户购买并使用这个应用（即SAAS应用）。SAAS应用往往是一个实例为多个SAAS用户提供服务。
# 另一种模式是：SAAS用户使用完全独立一个SAAS应用，包含独立应用实例及其后的数据源（如DB、缓存，etc）。
需要避免的SAAS应用拿到多个SAAS用户的数据。一个解决方法是处理过程关联好一个SAAS用户的上下文，在上下文中应用只能处理（读/写）这个SAAS用户的数据。请求由SAAS用户发起（如从Web请求进入App Engine），App Engine可以知道是从哪个SAAS用户，在Web请求时在上下文中设置好SAAS用户ID。应用处理数据（DB、Web、消息 etc.）是通过App Engine提供的服务SDK来完成。当应用处理数据时，SDK检查数据所属的SAAS用户是否和上下文中的SAAS用户ID一致，如果不一致则拒绝数据的读写。
应用代码会使用线程池，并且这样的使用是正常的业务需求。SAAS用户ID的从要App Engine传递到下层SDK，要支持这样的用法。
构架涉及3个角色：容器、用户应用、SDK。
整体流程：
- 请求进入
PAAS容器，提取上下文信息并设置好上下文。 - 进入用户应用处理业务，业务调用
SDK（如DB、消息、etc）。
用户应用会使用线程池，所以调用SDK的线程可能不是请求的线程。 - 进入
SDK处理。
提取上下文的信息，决定是否符合拒绝处理。
整个过程中，上下文的传递 对于 用户应用代码 期望是透明的。
由于不限制用户应用使用线程池，系统的上下文需要能跨线程的传递，且不影响应用代码。
Log4j2通过Thread Context提供了Mapped Diagnostic Context（MDC，诊断上下文）的功能，通过ThreadLocal/InheritableThreadLocal实现上下文传递。
在Thread Context文档中提到了在使用线程池等会缓存线程的组件（如Executors）时有问题，需要提供一个机制方案：
The Stack and the Map are managed per thread and are based on ThreadLocal by default. The Map can be configured to use an InheritableThreadLocal by setting system property isThreadContextMapInheritable to "true". When configured this way, the contents of the Map will be passed to child threads. However, as discussed in the Executors class and in other cases where thread pooling is utilized, the ThreadContext may not always be automatically passed to worker threads. In those cases the pooling mechanism should provide a means for doing so. The getContext() and cloneStack() methods can be used to obtain copies of the Map and Stack respectively.
即是TTL要解决的问题，提供Log4j2 MDC的TTL集成，详见工程log4j2-ttl-thread-context-map。
PS： 多谢 @bwzhang2011 和 @wuwen5 对日志场景说明交流和实现上讨论建议：