彻底理解ThreadLocal、ITL、TTL

最新推荐文章于 2024-04-16 09:00:46 发布

刘正权

最新推荐文章于 2024-04-16 09:00:46 发布

阅读量2.3k

点赞数 2

分类专栏： Java并发源码分析文章标签： java

本文链接：https://blog.csdn.net/liu765023051/article/details/112793426

版权

Java并发同时被 2 个专栏收录

1 篇文章 0 订阅

订阅专栏

源码分析

1 篇文章 0 订阅

订阅专栏

懒人改变了世界,简化了世界,却隐瞒了世界的真相.

大家好,今天跟大家剖析一下ThreadLocal.

文章目录

痛苦的回忆
抛几个问题
前奏铺垫
正片详解

痛苦的回忆

不知道大家有没有面向JDBC编程的经历.如果有的话,可以回想一下那是一种怎样的体验;如果没有,也可以假装有这样的经历,然后可以构想一下那是一种什么体验.
我体验过.太痛苦了!

由于要面向对象编程,我们的业务逻辑要写在Service层,然后一个Service内经常会用到多个dao层方法.
因为我们每次操作都要打开数据库连接,为了不经常打开/关闭数据库连接,我们需要在service层打开数据库连接,然后把数据库的connection传到dao层.service层处理完之后,再统一关闭数据库连接.
数据库连接是稀缺资源嘛.
注意:我们做了两件事:
1在service层的方法都要打开数据库连接,finally里面关闭连接.
2每个dao层接口,都要加一个connection参数.
每一个Service类的方法,都要写这么多程式化的代码,想想这个操作过程,再对比现在大家都在使用的简洁易用的SpringBoot,有多痛苦不言而喻了.

虽然SpringBoot以及这些类似的框架,简化了我们的工作量,但是我们需要知道,程序实际执行的时候,没一个打开连接、关闭连接的操作都是不能省略的,那框架是如何实现省略程式化开发,专注业务代码的呢?
动态修改字节码的AOP+ThreadLocal.
这里我就不给大家做实现了,相信大多数人也知道怎么玩.也欢迎你留言区一起讨论.

当然,ThreadLocal在做项目开发时,也会有很多应用.
比如,经过软负载的服务,有一些是存在状态的,当然实现方式有很多啦,假如使用请求携带token的方式,那么可以考虑ThreadLocal,这样在这次请求中,无论是验签,还是其他地方使用.利用ThreadLocal,你都可以少传递一个参数.

抛几个问题

我们是如何使用ThreadLocal的?
ThreadLocal如何工作的?
系统中的异步,基本都会依赖线程池,threadLocal和线程池可以同时使用么?
什么情况下会有内存泄漏的问题?
使用线程池+threadLocal时,主线程和子线程可以实现数据隔离么?
主线程和子线程可以实现数据共享么?
ThreadLocalMap内,为什么key做成弱引用,而value做成强引用?
InheritableThreadLocal 关于父子线程,ThreadLocal是如何处理的?

前奏铺垫

1、本文研究范围仅限Java8.
2、ThreadLocalMap
ThreadLocal内部维护了一个ThreadLocalMap静态内部类.ThreadLocalMap内部又维护了一个Entry静态内部类.静态内部类的作用,无疑就是对数据进行封装呗,不对外暴露.
我之前看源码时,经常会见到内部类 VS 静态内部类,因此我对此进行了较为详细的阐述:
https://blog.csdn.net/liu765023051/article/details/100884988

ThreadLocalMap提供了一种为ThreadLocal定制的高效实现，并且自带一种基于弱引用的垃圾清理机制。
ThreadLocalMap提供一个名为table的Entry数组.
Entry类内,使用ThreadLocal对象作为key,key为弱引用,变量值存储为value,value为强引用.

在这里插入图片描述

如图. 可知:ThreadLocalMap其实就是提供了一个名为table的Entry数组.该table为强引用,entry内key为ThreadLocal对象,且为弱饮用;entry内value为存储变量值,且为强引用.

3、ThreadLocalMap VS HashMap

在数据结构中,哈希是非常高效的一种思路.应用也非常广泛.数据库引擎有哈希索引,分库分表可以利用哈希进行,负载均衡都会有一种策略叫哈希策略等等.哈希随处可见.
哈希在JDK里面,实现时也是信手拈来.尽管实现方式有所不同,但是思路都是一样的,哈希算法有两个关键点:如何做散列的哈希算法、冲突后如何处理的冲突算法.
下面对比下ThreadLocalMap VS HashMap的冲突算法.

HashMap的数据结构比较清楚吧,数组+单链表.哈希冲突时,通过单链表解决哈希冲突.
即散列冲突时,遍历链表,以定位数据.

ThreadLocalMap是如何做散列的呢?
ThreadLocalMap使用一个名为table的Entry数组,但是Entry没有使用单链表,而是使用了线性探测的方式,解决哈希冲突.
所以,这个Entry数组,其实是一个逻辑环.
(线性探测自己去了解一下哦,此处不细讲)

环形示意图:

环形逻辑:

/**
 * 负载因子为2/3,初始容量默认16,设置扩容阈值.
 */
private void setThreshold(int len) {
    threshold = len * 2 / 3;
}

/**
 * 获取下一个元素索引
 */
private static int nextIndex(int i, int len) {
    return ((i + 1 < len) ? i + 1 : 0);
}

/**
 * 获取上一个元素索引
 */
private static int prevIndex(int i, int len) {
    return ((i - 1 >= 0) ? i - 1 : len - 1);
}

4、调试ThreadLocal源代码时,尽量要创建新线程,在新线程内调试.原因很简单.线程对象里面有ThreadLocalMap对象的引用.
Main函数是主线程,运行时,会初始化主线程需要的ThreadLocalMap信息.对你Debug算是一种干扰.

正片详解

什么是ThreadLocal？
顾名思义,ThreadLocal可以理解为线程本地变量。也就是说如果定义了一个ThreadLocal，每个线程往这个ThreadLocal中读写是线程隔离，各个线程之间是不会影响的。
它提供了一种将可变数据,通过每个线程有自己的独立副本 ,从而实现线程封闭的机制。

ThreadLocal大致的实现思路是怎样的？
Thread类有一个类型为ThreadLocal.ThreadLocalMap的实例变量threadLocals，也就是说每个线程有一个自己的ThreadLocalMap。
ThreadLocalMap有自己的独立实现，可以简单地将它的key视作ThreadLocal，value为代码中放入的值（实际上key并不是ThreadLocal本身，而是它的一个弱引用）。每个线程在往某个ThreadLocal里设置值的时候，都会往自己的ThreadLocalMap里存，读也是以某个ThreadLocal作为引用，在自己的map里找对应的key，从而实现了线程隔离。

其实理解ThreadLocal有一个弯,也是ThreadLocal有意思的地方:
一个线程内,可以使用多个ThreadLocal;多个线程间完全隔离.

怎么理解呢?
一个线程内,可以使用多个ThreadLocal.
一个线程对象内部,维护了一个ThreadLocalMap对象,该对象内存储了该线程内所有创建的ThreadLocal.
ThreadLocalMap对象内,使用ThreadLocal对象做Key,相应的待存储的变量为value.这样就实现了一个线程内,可以使用多个ThreadLocal变量.这多个ThreadLocal变量通过一个ThreadLocalMap维护.

多个线程间完全隔离.
一个线程对象内部,维护了一个ThreadLocalMap对象,即多个线程,会分别维护他们自己的ThreadLocal对象.通过对象隔离,实现数据隔离.

ThreadLocal是如何工作的?
线程对象thread,持有一个ThreadLocalMap对象,ThreadLocalMap对象内持有entry数组,名为table,
entry内key就是ThreadLocal对象,value为相应的变量value.

所以,可以通过ThreadLocal对象,获取value 的值,这个实现过程等价于该线程对象所保存的值.

在这里插入图片描述

如图, 该线程对象ThreadObjA,成员变量threadLocals持有强引用,即ThreadLocalMap,
threadLocals跟ThreadLocalMap是聚合关系,注意是聚合,不是组合.关于这组关系,本文不细讲,以后讲设计模式的时候,碰到这组关系时,好好讲讲.
ThreadLocalMap对象持有名为table的Entry数组,每个entry又用弱引用ThreadLocalRef1做key,变量作为value.

此外,该线程对象内,又创建了threadLocalRef1和threadLocalRef2两个对象.
易知:线程执行完毕,方法出栈.该线程内的变量threadLocalRef1和threadLocalRef2,以及线程对象的成员变量threadLocals,它们的强引用均消失.
那么垃圾回收时,从GCRoot分析可达性时,该ThreadLocalMap和ThreadLocalObj对象率先失去强引用.
先分析ThreadLocalMap,垃圾回收时优先会被回收,其次是名为table的entry数组,然后是value值.
再看ThreadLocal对象,随着线程对象消亡,ThreadLocal对象也会优先失去强引用.仅仅被entry持有弱引用.
什么是弱引用呢?简单了解下,在垃圾回收器线程扫描内存区域时,一旦发现弱引用对象,不管当前内存空间是否足够,均会回收它的内存.但是,由于垃圾回收器是一个优先级很低的线程,因此不一定很快发现哪些具有若引用的对象.
总结一下:
Entry的key回收:就是失去了强引用的ThreadLocal对象,只剩下Entry的一条弱引用,随时可能会被回收掉.
Entry的value回收:因为存在一条从当前线程对象连接过来的一条强引用. 只有当前thread结束以后, 当前线程对象就不会存在栈中,强引用断开, 当前线程对象, ThreadLocalMap, value将全部被GC回收.

先总结一下这个例子
创建一个ThreadLocal对象,其实有两条引用指向了ThreadLocal对象.一个外引用,一个内引用.
在这个例子中,这个线程执行方式时,创建了两个ThreadLocal对象,其引用分别是:threadLocalRef1和threadLocalRef2.这两个引用可以看做是外引用.
内引用是指Thread–>ThreadLocalMap–>Entry–>Value这一条链.如图所示.共有weakRef1和weakRef2两个弱引用.

这是正常情况,对吧.那如果发生了异常线程并未退出呢?
如果线程执行时发生了异常,导致自己并未退出,那么该线程持有的成员变量threadLocals,以及内部创建的对象引用ThreadLocalRef,它们拥有的是强引用,均不会释放,那么该ThreadLocal在GC线程回收时,就会逃过GCroot追溯.
如果这样的线程越变越多,且内部的ThreadLocal及其相关的对象,每次都能比过gc线程的回收操作,那么就会导致了内存泄漏.

那线程池+ThreadLocal呢,真的会导致内存泄漏么?
极少情况,存在内存泄漏的可能.

1、正常情况下,会出现脏读.
如果是线程池在执行.我们知道,线程池内的线程,是会重复执行任务的.即线程池内某个线程在执行完某个任务之后,没有立即消亡,而是去执行另一个任务.
这时如果直接执行get方法,那么它就会读到上一个任务中的set的值,即脏数据.
注意,这时该线程对象所持有的强引用并未释放,即线程对象内的ThreadLocal对象,仍然持有强引用.
所以线程池+ThreadLocal,使用不当的话,会导致脏读.

所以,在使用线程池时,使用完ThreadLocal,应该调用threadLocal.remove方法,或者设置threadLocal的变量为null.便于gc线程回收.
同时,有可能会有脏读,但是不会出现内存泄漏.

2、那在使用线程池时,使用ThreadLocal,什么时候会导致内存泄漏呢?
正常情况下,线程对象都会被gc线程回收(同时相关threadLocalMap、entry、key、value等对象都会被回收),那这时就不会出现内存泄漏.
但是在ThreadLocal设为null,但是线程尚未结束,且要存活一段时间,那这时慢慢会达到一种:作为Entry的key的ThreadLocal对象已经回收了,为null了;而value却随线程存活而一直存在.
此时,我们假设该线程曾创建了10个ThreadLocal对象,那么此时,就会有10个Entry对象. 此时每个Entry对象key为null,value不为空.

此时,如果我们项目里面有了很多很多这样的线程,就有可能发生内存泄漏.

此时有几个注意点:
1、如果key不设置成null,那么就不构成内存泄漏了,因为这种情况,栈内引用持有着ThreadLocal的强引用,会被认为是该ThreadLocal还在被正常使用;
2、此时,这样很多很多的线程,同时不使用threadLocal的方法.即:get、set、remove方法.
因为ThreadLocal开发者在value的可用性与内存泄漏的可能性之间做了权衡 ,即分别在get、set、remove方法内,对key为null的Entry进行了处理.即如果你调用了任意一个threadLocal对象的get、set、remove方法,就会检查相应key为null的Entry,并进行清理.
3、更多情况,ThreadLocalMap内会一直累加之前存储过的KV,即过多无意义的Entry对象.少数使用不当的情况会发生脏读.

在ThreadLocalMap中,Entry中的key,即ThreadLocal为什么要使用弱引用呢?
这就比较好理解了.
因为ThreadLocal在没有外部强引用来引用它的时候,那么ThreadLocal可以被GC线程回收.
如果Entry中的key即,ThreadLocal为强引用,那么该ThreadLocal对象,只有在ThreadLocalMap、table都被回收了之后,才有可能被回收.即ThreadLocalMap不会回收,ThreadLocal永远不会被gc线程回收.
所以,此处设计成弱引用,提前了ThreadLocal的可gc时间.

那好,现在ThreadLocal使用完了,执行了threadLocal==null操作,那么该ThreadLocal就只剩下这个一个内部entry的弱引用了,可以随时被gc线程回收了.
ThreadLocal被回收完之后,那么此时就会出现一个Entry中key为null,value却存在的情况.
如果该线程生活周期很长,那么ThreadLocalMap对象一定一直存在.因为该线程对象内部的持有ThreadLocalMap的强引用.这些key为null的entry就会存在一条强引用链的关系:
Thread–>ThreadLocalMap–>Entry–>Value.这条强引用链会导致Entry、value、ThreadLocalMap都不会被回收,有可能会造成内存泄漏.上面已经分析过这种情况.

那为什么Entry中的value,即变量值要使用强引用呢?
这也是JVM团队严谨的考虑吧.像上面,执行了threadLocal==null操作之后,threadLocal对象只剩下一个弱引用,可能随时被gc线程回收.
但是这时,注意这时,你的ThreadLocal使用完了,但是你的业务逻辑并未处理完,你的程序仍继续运行,并且还会使用该value值,那这时候,该value仍然可以使用.
JVM设计的工具类,考虑的角度,确实很全面(真的是把使用者当猪一样啊),不过这种理念设计出来的软件,确实才更加严谨.

OK,value使用强引用有道理.那么此处的value什么时候回收呢?
首先,Thread线程对象销毁了,那么这一个null链条肯定有机会被gc线程回收了;
然后你看源码会发现,当你调用ThreadLocal的get、set、remove方法时,它都回去检查key为null的entry.key为null时,释放value对象所占空间.
此处这样做,也是极大可能避免垃圾堆积吧.
此时,设置Entry的key=null,基本就可以保证不会造成内存泄漏了.
比较好理解吧.key=null了,ThreadLocal被回收了,只要你执行该线程上其他ThreadLocal对象的get、set、remove方法,都会去处理对应的key为null时的Entry对象,释放其空间.

线程池+ThreadLocal,推荐使用方式
不过,做好使用ThreadLocal的方式,还是在使用完之后,在finally里面调用一下threadLocal的remove方法.
主动删除entry,完全避免因ThreadLocal可能导致内存泄漏的可能性.提前threadLocal的gc时间.

InheritableThreadLocal 关于父子线程,ThreadLocal是如何处理的?

ThreadLocal声明的变量是线程私有的成员变量，每个线程都有该变量的副本，线程对变量的修改对其他线程不可见.

InheritableThreadLocal声明的变量同样是线程私有的，但是子线程可以使用同样的InheritableThreadLocal类型变量从父线程继承InheritableThreadLocal声明的变量，父线程无法拿到其子线程的。即使可以继承，但是子线程对变量的修改对父线程也是不可见的。

/* ThreadLocal values pertaining to this thread. This map is maintained

by the ThreadLocal class. */
ThreadLocal.ThreadLocalMap threadLocals = null;

InheritableThreadLocal values pertaining to this thread. This map is
maintained by the InheritableThreadLocal class.
*/
ThreadLocal.ThreadLocalMap inheritableThreadLocals = null;

ThreadLocal VS InheritableThreadLocal VS TransmittableThreadLocal

ThreadLocal线程变量副本,实现线程隔离,也可以实现父子线程隔离;

InheritableThreadLocal子类,可以访问到父类ThreadLocal的变量值.即父线程修改的值,可以使用InheritableThreadLocal子类,使子线程获取到父类更新的变量;子线程只能用，修改了不会影响父线程的东西.
严谨一些的说法是 :在创建子线程时,将父线程当前存在的本地线程变量拷贝到子线程的本地线程变量中。

具体是如何操作的呢?
在创建 Thread 类对象时,将父线程中的 table 对象以复制的方式赋值给子线程的 table 数组.也就是说当子线程对象创建完毕后,子线程中的数据就是主线程中旧的数据，主线程使用新的数据时，子线程还是使用旧的数据,因为主子线程使用两个 Entry[] 对象数组各自存储自己的值.
此时需要看一下代码:
private ThreadLocalMap(ThreadLocalMap parentMap) {
Entry[] parentTable = parentMap.table;
int len = parentTable.length;
setThreshold(len);
table = new Entry[len];

for (int j = 0; j < len; j++) {
    Entry e = parentTable[j];
    if (e != null) {
        @SuppressWarnings("unchecked")
        ThreadLocal<Object> key = (ThreadLocal<Object>) e.get();
        if (key != null) {
            Object value = key.childValue(e.value);
            Entry c = new Entry(key, value);
            int h = key.threadLocalHashCode & (len - 1);
            while (table[h] != null)
                h = nextIndex(h, len);
            table[h] = c;
            size++;
        }
    }
}

}

第13行,调用了key.childValue方法.这里涉及了Java的值传递. 默认实现采用了浅拷贝.就是不管父线程value里面存储的是基本数据类型还是对象类型,都直接赋值到子线程对应的Entry内.

稍微解释一下:

对于对象类型来说，值的内容其实是对象的引用。当在父线程中修改对象的某一属性，由于子线程引用着相同对象，所以可以子线程可以感知到，本质上父线程和子线程在操作同一块内存地址,即同一个value。

对于基本数据类型来说，由于传递的是值，在父线程改变了数据后，子线程依旧使用的是旧的数据。
这里尤其要提 String 字符串，String 虽然不是基本数据类型，但是由于内部字符数组被 final 修饰带来的不可变型，
当父线程修改其 String 类型数据时，等于替换掉该 String 对象，而并不是修改原 String 对象的值.
所以子线程创建后,父线程值修改时,子线程内的value依旧不会发生变化。

这里的key.childValue()方法,是JDK的默认实现,在创建InheritableThreadLocal时,可以由使用者自行重写.

由的实现,可知其有局限性.父线程变量复制到子线程的时机,是在子线程创建的时候.
InheritableThreadLocal + 线程池时,线程池中的线程拷贝的数据来自于第一个提交任务的外部线程.
即后面的外部线程向线程池中提交任务时，子线程访问的本地变量都来源于第一个外部线程，造成线程本地变量混乱.

TransmittableThreadLocal对此做了改进.在线程池模式下，也可以很好的将父线程本地变量传递下去.

TransmittableThreadLocal有哪些应用呢?官方给出了应用场景:
分布式跟踪系统或全链路压测（即链路打标）
日志收集记录系统上下文
Session级Cache
应用容器或上层框架跨应用代码给下层SDK传递信息

InheritableThreadLocal不支持线程池的根本原因是InheritableThreadLocal是在父线程创建子线程时复制的，由于线程池的复用机制，“子线程”只会复制一次。
不实用线程池时,没有问题.
要支持线程池中能访问提交任务线程的本地变量，其实只需要在父线程向线程池提交任务时复制父线程的上下环境，那在子线程中就能够如愿访问到父线程中的本地变量，实现本地环境变量在线程池调用中的透传这也就是TransmittableThreadLocal最本质的实现原理.

TransmittableThreadLocal是阿里实现的.具体的实现也很精妙.
我们一起来简单看一下.
TransmittableThread继承了InheritableThreadLocal,并丰富了它的功能.
InheritableThreadLocal是在子线程创建的时候,将父线程内变量,复制给子线程,所以出现了上述的问题:线程池+InheritableThreadLocal,导致变量混乱.
TransmittableThreadLocal相比于InheritableThreadLocal,做了改进:
1、TransmittableThreadLocal内部保存了父线程的上下文,即名为holder的全局静态变量.在执行get、set时,会将对应的value,维护在holder中;
2、在向线程池提交任务时,会通过重放、和恢复,帮助子线程同步主线程的变量值.

总结

本文试图站在一个大而全的角度,分析一下ThreadLocal以及相关的实现.
希望对你有所收获.

引用:
git官网:https://github.com/alibaba/transmittable-thread-local
源码:https://github.com/alibaba/transmittable-thread-local/blob/master/src/main/java/com/alibaba/ttl/TransmittableThreadLocal.java
不错的文章:https://mp.weixin.qq.com/s/a6IGrOtn1mi0r05355L5Ng

刘正权

关注

2
点赞
踩
10

收藏

觉得还不错? 一键收藏
4
评论
彻底理解ThreadLocal、ITL、TTL

懒人改变了世界,简化了世界,却隐瞒了世界的真相.大家好,今天跟大家剖析一下ThreadLocal.文章目录痛苦的回忆抛几个问题前奏铺垫正片详解痛苦的回忆不知道大家有没有面向JDBC编程的经历.如果有的话,可以回想一下那是一种怎样的体验;如果没有,也可以假装有这样的经历,然后可以构想一下那是一种什么体验.我体验过.太痛苦了!由于要面向对象编程,我们的业务逻辑要写在Service层,然后一个Service内经常会用到多个dao层方法.因为我们每次操作都要打开数据库连接,为了不经常打.
复制链接

扫一扫