//⑶ task2的异步任务逻辑中期望获取⑵中的上下文
Runnable task2 = () -> {
String manTaskCtx = THREAD_LOCAL.get();
System.out.println(“task2:” + Thread.currentThread() + “, get ctx :” + manTaskCtx);
};
//⑷ 转换为TransmittableThreadLocal 增强的Runnable
//task2 = TtlRunnable.get(task2);
EXECUTOR.submit(task2);
}finally {
THREAD_LOCAL.remove();
}
}
public static void main(String[] args) throws InterruptedException {
testThreadLocal();
}
}
//InheritableThreadLocal 运行结果：
task1:Thread[TTL-TEST-0,5,main], get ctx:set-task-init-value
task2:Thread[TTL-TEST-0,5,main], get ctx :null
//TransmittableThreadLocal 运行结果
task1:Thread[TTL-TEST-0,5,main], get ctx:set-task-init-value
task2:Thread[TTL-TEST-0,5,main], get ctx :main-task-value
通过代码运行结果，我们可以直观看到使用JDK原生InheritableThreadLocal，在task2异步任务中是无法正确获取代码⑵处所设置的上下文参数，只有改用TransmittableThreadLocal之后，程序才如我们预期正常获取。
不难发现，由JDK原生ThreadLocal切换到TransmittableThreadLocal，只需要做极少量的代码适配即可。
//private static ThreadLocal THREAD_LOCAL = new InheritableThreadLocal<>();
//⑴ 声明TransmittableThreadLocal类型的ThreadLocal
private static ThreadLocal THREAD_LOCAL = new TransmittableThreadLocal<>();
…
//⑷ 转换为TransmittableThreadLocal 增强的Runnable
task2 = TtlRunnable.get(task2);
相信看到这里我们都会不禁想问，为什么只需要简单的更改两行代码，就可以平滑实现上下文透传？TTL框架背后具体都做了哪些工作，到底是怎么实现的呢？相信你和我一样都会比较好奇，也一定有想立马阅读源码一探究竟的冲动。
不过，通常这个时候，我并不会一头扎进源码，一般都会先做几项准备工作，一是回到设计文档再仔细的阅读下相关实现方案，把关键流程和原理了解清楚；二是把涉及到的技术体相关的基础知识再复习或学习一遍，以避免由于一些基础知识原理的不了解，导致源码无法深入研究或花费大量精力。像这里如果我对Thread、ThreadLocal、InheritableThreadLocal、线程池等相关知识不熟悉的话，一定会把相关知识先学习一遍，比如ThreadLocal基本原理、底层数据结构、InheritableThreadLocal如何实现父子线程传递等等。
假设这里你对这些知识都已掌握，如果不熟悉，网上相关介绍文章也早已是汗牛充栋，你搜索学习下即可。这里我们先带着到底如何实现的这个疑问，一起来探究下核心源码实现。
首先把源码clone下来导入IDE，然后结合文档把系统工程结构和各功能模块职责快速熟悉一遍，然后结合文档和Demo找到关键接口和实现类，利用IDE把相关类图结构生成出来，以便快速理解类之间关系。非常不错，TTL整体代码非常精练、命名和包信息描述也都非常规范和清晰，我们可以快速圈出来。
从类图中我们可以清晰看到核心关键类TransmittableThreadLocal是从ThreadLocal继承而来，这样的好处是不破坏ThreadLocal原生能力的同时还可增强和扩展自有能力，也可保证业务代码原有互操作性和最小改动。
然后结合Demo代码，我们不难发现使用TTL主要有三个步骤，TransmittableThreadLocal声明、set、remove方法的调用。根据整个使用流程和方法调用栈，我们也可以很方便梳理出整个代码处理初始化、调用时序。
(这里借用官方原图)
通过流程图，我们可以清晰看到TTL核心流程和原理是通过TransmittableThreadLocal.Transmitter 抓取当前线程的所有TTL值并在其他线程进行回放，然后在回放线程执行完业务操作后，再恢复为回放线程原来的TTL值。
TransmittableThreadLocal.Transmitter提供了所有TTL值的抓取、回放和恢复方法（即CRR操作）：
capture方法：抓取线程（线程A）的所有TTL值。
replay方法：在另一个线程（线程B）中，回放在capture方法中抓取的TTL值，并返回 回放前TTL值的备份
restore方法：恢复线程B执行replay方法之前的TTL值（即备份）
弄明白核心流程和原理后，我们现在来分析下相关核心代码，在声明TransmittableThreadLocal变量时，我们会发现框架初始化了一个类级别的变量holder用于存储用户设置的所有ttl上下文，也是为了后续执行capture抓取时使用。
// Note about the holder:
// 1. holder self is a InheritableThreadLocal(a ThreadLocal).
// 2. The type of value in the holder is WeakHashMap<TransmittableThreadLocal, ?>.
// 2.1 but the WeakHashMap is used as a Set:
// the value of WeakHashMap is always null, and never used.
// 2.2 WeakHashMap support null value.
private static final InheritableThreadLocal<WeakHashMap<TransmittableThreadLocal, ?>> holder =
new InheritableThreadLocal<WeakHashMap<TransmittableThreadLocal, ?>>() {
@Override
protected WeakHashMap<TransmittableThreadLocal, ?> initialValue() {
return new WeakHashMap<TransmittableThreadLocal, Object>();
}
@Override
protected WeakHashMap<TransmittableThreadLocal, ?> childValue(WeakHashMap<TransmittableThreadLocal, ?> parentValue) {
return new WeakHashMap<TransmittableThreadLocal, Object>(parentValue);
}
};
/**
- see {@link InheritableThreadLocal#set}
*/
@Override
public final void set(T value) {
if (!disableIgnoreNullValueSemantics && null == value) {
// may set null to remove value
remove();
} else {
super.set(value);
addThisToHolder();
}
}
private void addThisToHolder() {
if (!holder.get().containsKey(this)) {
holder.get().put((TransmittableThreadLocal) this, null); // WeakHashMap supports null value.
}
}
结合set方法实现来看，我们会发现holder变量设计的非常巧妙，业务设置的上下文value部分继续复用ThreadLocal原有数据结构ThreadLocalMap来存储( super.set(value))；capture的数据源利用holder进行引用存储(addThisToHolder put this)。这样的好处是既可保持ThreadLocal数据存储原有的封装性，又很好实现扩展。除此之外，holder还有其他设计考究，这里抛出来大家可以思考下：
-
为什么holder需要设计成static final类级别变量？
-
ttl变量的存储为什么需要使用WeakHashMap，而不是hashmap或其他？
然后我们再来看异步task转换 TtlRunnable.get(task2) 核心代码实现，代码整体实现相对比较简单，get方法是一个静态工厂方法，主要作用是将业务传入的普通Runnable task装饰成TtlRunable类，并在TtlRunable构造方法中进行线程capture动作(具体实现我们后面再分析)，然后将结果存储到对象属性capturedRef中。
@Nullable
public static TtlRunnable get(@Nullable Runnable runnable, boolean releaseTtlValueReferenceAfterRun, boolean idempotent) {
if (null == runnable) return null;
if (runnable instanceof TtlEnhanced) {
// avoid redundant decoration, and ensure idempotency
if (idempotent) return (TtlRunnable) runnable;
else throw new IllegalStateException(“Already TtlRunnable!”);
}
//将入参runnable进行了装饰
return new TtlRunnable(runnable, releaseTtlValueReferenceAfterRun);
}
//…
public final class TtlRunnable implements Runnable, TtlWrapper, TtlEnhanced, TtlAttachments {
private final AtomicReference capturedRef;
private final Runnable runnable;
private final boolean releaseTtlValueReferenceAfterRun;
private TtlRunnable(@NonNull Runnable runnable, boolean releaseTtlValueReferenceAfterRun) {
this.capturedRef = new AtomicReference(capture());
this.runnable = runnable;
this.releaseTtlValueReferenceAfterRun = releaseTtlValueReferenceAfterRun;
}
/**
- wrap method {@link Runnable#run()}.
*/
@Override
public void run() {
final Object captured = capturedRef.get();
if (captured == null || releaseTtlValueReferenceAfterRun && !capturedRef.compareAndSet(captured, null)) {
throw new IllegalStateException(“TTL value reference is released after run!”);
}
final Object backup = replay(captured);
try {
runnable.run();
} finally {
restore(backup);
}
}
//…
｝
然后是run方法，这也是核心关键的CRR操作了。这里通过模板方法将CRR操作编排在业务逻辑执行的前后了，也即业务逻辑执行前会将capturer的值进行replay恢复，执行后进行复原restore操作。同样这里也有几个问题很值我们思考：
-
capture操作为什么需要放到TtlRunnable构造方法中，而不能在run方法中？
-
代码中使用了哪两个设计模式，使用设计模式的好处是什么？
-
业务执行完之后为什么还需要restore操作？
接下来，我们再分别对capture、replay、restore方法实现做个一一分析。首先是capture方法，我们可以看到capture操作整体比较简单，主要是将set操作保存到holder变量中的值进行遍历并以Snapshot结构进行存储返回。
/**
-
Capture all {@link TransmittableThreadLocal} and registered {@link ThreadLocal} values in the current thread.
-
@return the captured {@link TransmittableThreadLocal} values
-
@since 2.3.0
*/
@NonNull
public static Object capture() {
return new Snapshot(captureTtlValues(), captureThreadLocalValues());
}
private static HashMap<TransmittableThreadLocal, Object> captureTtlValues() {
HashMap<TransmittableThreadLocal, Object> ttl2Value = new HashMap<TransmittableThreadLocal, Object>();
for (TransmittableThreadLocal threadLocal : holder.get().keySet()) {
ttl2Value.put(threadLocal, threadLocal.copyValue());
}
return ttl2Value;
}
private static HashMap<ThreadLocal, Object> captureThreadLocalValues() {
final HashMap<ThreadLocal, Object> threadLocal2Value = new HashMap<ThreadLocal, Object>();
for (Map.Entry<ThreadLocal, TtlCopier> entry : threadLocalHolder.entrySet()) {
final ThreadLocal threadLocal = entry.getKey();
final TtlCopier copier = entry.getValue();
threadLocal2Value.put(threadLocal, copier.copy(threadLocal.get()));
}
return threadLocal2Value;
}
另一个captureThreadLocalValues，主要是用于将一些已有ThreadLocal中的上下文一起复制，已有ThreadLocal需要通过registerThreadLocal方法来单独注册。相关代码如下：
public static class Transmitter {
//…
private static volatile WeakHashMap<ThreadLocal, TtlCopier> threadLocalHolder = new WeakHashMap<ThreadLocal, TtlCopier>();
private static final Object threadLocalHolderUpdateLock = new Object();
//…
public static boolean registerThreadLocal(@NonNull ThreadLocal threadLocal, @NonNull TtlCopier copier, boolean force) {
if (threadLocal instanceof TransmittableThreadLocal) {
logger.warning(“register a TransmittableThreadLocal instance, this is unnecessary!”);
return true;
}
synchronized (threadLocalHolderUpdateLock) {
if (!force && threadLocalHolder.containsKey(threadLocal)) return false;
WeakHashMap<ThreadLocal, TtlCopier> newHolder = new WeakHashMap<ThreadLocal, TtlCopier>(threadLocalHolder);
newHolder.put((ThreadLocal) threadLocal, (TtlCopier) copier);
threadLocalHolder = newHolder;
return true;
}
}
//…
}
这里代码有个非常关键的处理，由于WeakHashMap非线程安全，为了避免并发问题安全加上了synchronized锁操作。这里有可以思考下除了synchronized关键字还有什么保障线程安全的方法。另外，实现threadLocal注册时为已经在锁块中了，为什么还要做new copy重新替换操作，这样做目的是什么？大家可以想想看。
最后就是replay和restore方法，整体实现逻辑非常清晰，主要是将captured的值在当前线程ThreadLocal中进行重新赋值初始化，以及业务执行后恢复到原来。这里很佩服作者对不同情况的细致考虑，不是直接将当前holder中的上下文直接备份，而是与之前已capture的内容比较，将业务后set的上下文进行剔除，以免在恢复restore时出现前后不一致的情况。
@NonNull
public static Object replay(@NonNull Object captured) {
final Snapshot capturedSnapshot = (Snapshot) captured;
return new Snapshot(replayTtlValues(capturedSnapshot.ttl2Value), replayThreadLocalValues(capturedSnapshot.threadLocal2Value));
}
@NonNull
private static HashMap<TransmittableThreadLocal, Object> replayTtlValues(@NonNull HashMap<TransmittableThreadLocal, Object> captured) {
HashMap<TransmittableThreadLocal, Object> backup = new HashMap<TransmittableThreadLocal, Object>();
for (final Iterator<TransmittableThreadLocal> iterator = holder.get().keySet().iterator(); iterator.hasNext(); ) {
TransmittableThreadLocal threadLocal = iterator.next();
// backup
backup.put(threadLocal, threadLocal.get());
// clear the TTL values that is not in captured
// avoid the extra TTL values after replay when run task
if (!captured.containsKey(threadLocal)) {
iterator.remove();
threadLocal.superRemove();
}
}
// set TTL values to captured
setTtlValuesTo(captured);
// call beforeExecute callback
doExecuteCallback(true);
return backup;
}
private static void setTtlValuesTo(@NonNull HashMap<TransmittableThreadLocal, Object> ttlValues) {
for (Map.Entry<TransmittableThreadLocal, Object> entry : ttlValues.entrySet()) {
TransmittableThreadLocal threadLocal = entry.getKey();
threadLocal.set(entry.getValue());
}
}
public static void restore(@NonNull Object backup) {
final Snapshot backupSnapshot = (Snapshot) backup;
restoreTtlValues(backupSnapshot.ttl2Value);
restoreThreadLocalValues(backupSnapshot.threadLocal2Value);
}
private static void restoreTtlValues(@NonNull HashMap<TransmittableThreadLocal, Object> backup) {
// call afterExecute callback
doExecuteCallback(false);
for (final Iterator<TransmittableThreadLocal> iterator = holder.get().keySet().iterator(); iterator.hasNext(); ) {
TransmittableThreadLocal threadLocal = iterator.next();
// clear the TTL values that is not in backup
// avoid the extra TTL values after restore
if (!backup.containsKey(threadLocal)) {
iterator.remove();
threadLocal.superRemove();
}
}
// restore TTL values
setTtlValuesTo(backup);
}
核心代码分析完之后，再来简单总结下项目中学习到的知识点：
-
对ThreadLocal、InheritableThreadLocal有了更加系统和深入的理解，包括两者继承关系、底层数据结构ThreadLocalMap与Thread关联关系等。
-
面向gc编程(gc相关)、WeakHashMap(Java对象引用类型强、软、弱等)、线程安全、并发等等
-
设计模式相关，装饰模式、工厂、模板方法、代理等
-
TTL虽然代码量不算多，但短小精悍，也处处体现了作者超高的设计和编程能力，每行代码都值得学习和反复琢磨。
我相信通过类似这样的一个项目学习流程下来，把每个环节都能踏踏实实做好，且过程中有贯穿自己思考和理解。相信你一定能把每个项目吃透，并把项目中的每个技术点都牢牢掌握。
最后，我所在团队是淘系技术部淘系架构团队，主要在负责一站式serverless研发平台建设，为业务不断提升研发效率和极致体验。平台已平稳支撑淘系互动、淘宝人生、金币庄园、特价版、闲鱼、拍卖、品牌轻店等多个业务的6.18、双11、双12、春晚等多个大促活动。
自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。
深知大多数Java工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！
因此收集整理了一份《2024年Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。
既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Java开发知识点，真正体系化！
由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！
如果你觉得这些内容对你有帮助，可以扫码获取！！（备注Java获取）
最后，附一张自己面试前准备的脑图：
面试前一定少不了刷题，为了方便大家复习，我分享一波个人整理的面试大全宝典
- Java核心知识整理
- Spring全家桶（实战系列）
Step3：刷题
既然是要面试，那么就少不了刷题，实际上春节回家后，哪儿也去不了，我自己是刷了不少面试题的，所以在面试过程中才能够做到心中有数，基本上会清楚面试过程中会问到哪些知识点，高频题又有哪些，所以刷题是面试前期准备过程中非常重要的一点。
以下是我私藏的面试题库：
很多人感叹“学习无用”，实际上之所以产生无用论，是因为自己想要的与自己所学的匹配不上，这也就意味着自己学得远远不够。无论是学习还是工作，都应该有主动性，所以如果拥有大厂梦，那么就要自己努力去实现它。
最后祝愿各位身体健康，顺利拿到心仪的offer！
《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取！
mg.cn/images/e5c14a7895254671a72faed303032d36.jpg" alt=“img” style=“zoom: 33%;” />
最后，附一张自己面试前准备的脑图：
[外链图片转存中…(img-DVSPiAcJ-1713633736924)]
面试前一定少不了刷题，为了方便大家复习，我分享一波个人整理的面试大全宝典
- Java核心知识整理
[外链图片转存中…(img-zFDQPjhr-1713633736925)]
- Spring全家桶（实战系列）
[外链图片转存中…(img-eAZDkELU-1713633736925)]
Step3：刷题
既然是要面试，那么就少不了刷题，实际上春节回家后，哪儿也去不了，我自己是刷了不少面试题的，所以在面试过程中才能够做到心中有数，基本上会清楚面试过程中会问到哪些知识点，高频题又有哪些，所以刷题是面试前期准备过程中非常重要的一点。
以下是我私藏的面试题库：
[外链图片转存中…(img-QJ9NFg4G-1713633736925)]
很多人感叹“学习无用”，实际上之所以产生无用论，是因为自己想要的与自己所学的匹配不上，这也就意味着自己学得远远不够。无论是学习还是工作，都应该有主动性，所以如果拥有大厂梦，那么就要自己努力去实现它。
最后祝愿各位身体健康，顺利拿到心仪的offer！
《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取！
5万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
