与Synchonized的比较,它的作用是什么
ThreadLocal和Synchonized都用于解决多线程并发访问。可是ThreadLocal与Synchronized有着本质的区别。Synchronized是利用锁的机制,使变量或代码代码块在某一个时刻仅仅能被一个线程访问。
从名字我们就可以看到ThreadLocal叫做线程变量,意思是ThreadLocal中填充的变量属于当前线程,该变量对其他线程而言是隔离的。ThreadLocal为变量在每个线程中都创建了一个副本,那么每个线程可以访问自己内部的副本变量。
从字面意思非常容易理解,但是从实际使用的角度来看就没那么容易了。作为一个面试常问的点,使用场景那也是相当的丰富。
1. 在进行对象跨层次传递的时候,使用ThreadLocal可以避免多次传递,打破层次间的束缚。
2. 线程间层次隔离。
3. 进行事务操作,用于存储线程事务信息。
4. 数据库连接,Session会话管理。
现在应该对ThreadLocal已经有一个大概的认识了。下面看看具体如何使用。
ThreadLocal怎么使用
既然ThreadLocal的作用是每一个线程创建一个副本,那我们使用一个例子来验证一下:
注:为什么说,ThreadLocal用于局部变量是笨蛋呢?继续看后面的文章会让你大彻大悟的。
从结果可知,每一个线程都有各自的local值。也就是说,threadLocal的值是线程与线程分离的。具体原理可以画出以下不同线程中ThreadLocalMap是如何存储数据的。
如果是第一次学习ThreadLocal的朋友可能看懵了,ThreadLocal我都没看懂,你跟我说ThreadLocalMap?别急,我们接着往下看。
从这张图中可以看到:每一个线程对应了一个ThreadLocalMap,每一个ThreadLocal又包含一个Entry数组。数组的key是我们的ThreadLocal对象,并且是多个线程共享的key,value则是每个线程中各是各的独一份。
ThreadLocal的使用场景—数据库连接
我们知道,数据库连接池最为我们诟病的就是连接的创建与关闭。这其中要耗费大量的资源与时间。我们的ThreadLocal也可以帮我们解决这个问题。
这是一个数据库连接的管理类。我们在使用数据库的时候首先就是建立数据库连接。然后用完了之后就关闭。这样做有一个很严重的问题,如果有1个用户频繁使用数据库,那么就需要建立多次连接和关闭。这样我们服务器可能吃不消,那么怎么办呢?如果一万个客户端,那么服务器压力更大。
这时最好使用ThreadLocal。因为ThreadLocal在每个线程中会创建一个副本。并且在线程内部任何地方可以使用。线程之间互不影响。这样一来就不存在线程安全问题,也不会严重影响程序执行性能,避免了connection的频繁创建和销毁。(当然实际中我们有数据库连接池可以处理,但我们的目的都很明确,避免连接对象的频繁创建与销毁!)
以上主要讲解了一个基本的案例,然后还分析了为什么在数据库连接的时候会使ThreadLocal。下面我们从源码的角度分析ThreadLocal的工作原理。
ThreadLocal源码分析
ThreadLocal类接口简介
ThreadLocal类接口很简单,只有4个方法,先来了解一下:
1. void set(Object value);//设置当前线程的线程局部变量值
2. public Object get();//该方法返回当前线程所对应的线程局部变量
3. public void remove();//当线程局部变量的值删除,目的是为了减少内存的占用。该方法是JDK5.0新增的方法,需要指出的是,当前线程结束后,对应该线程的局部变量将自动被垃圾回收,所以调用该方法清除线程的局部变量并不是必须的操作,但它可以加快内存回收的速度。
4. protected Object initialValue()//返回该线程局部变量的初始值,该方法是一个protected方法,显然是为了让子类覆盖而设计的。这个方法是一个延迟调用方法,在线程第1次调用get()或set(Object)时才执行,并且仅执行1次。如果不写initialValue,那么第一次调用get()会返回一个null。
新建一个ThreadLocal对象:
public final static ThreadLocal<String> resourse = new ThreadLocal<String>(); resourse仅代表一个能够存放String类型的ThreadLocal对象。此时不论什么线程并发访问这个变量,对它进行写入,读取操作,都是线程安全的。
由源码一步一步画出经典流程图
我们根据ThreadLocal在实际开发中的使用流程,把网上到处传遍的经典流程图一步步画出来。(认真看,百分百看懂吊打面试官!)
实际上,画出这个图,只需要三行代码即可。注意:ThreadLocal设置为局部方法仅仅为了写例子。ThreadLocal如果设置为了局部变量将失去他本身将线程隔离的特性作用。完全就是核弹打蚂蚁的操作!
首先,如第1步,我们new出一个ThreadLocal对象。
我们知道,ThreadLocal如果不进行set,是没有任何数据的,于是我们进行步骤2开始set一个值。点进set看源码!
点进ThreadLocal的set方法,我们发现它第一步就获取了当前线程的对象。注意,这个当前线程的对象的生命周期是与当前线程同步的。于是更新流程图:
然后我们根据当前线程对象,获取了ThreadLocalMap(这个ThreadLocalMap并不是一直存在的,而是检测我们当前现成是否存在这个ThreadLocalMap对象,如果不存在会先进行对象创建,否则直接获取ThreadLocalMap对象)。于是更新流程:
在获取map对象后,我们开始对当前线程的ThreadLocalMap对象进行set操作。
注意,此处的set的key是this。此时的this对象正是我们的ThreadLocal的对象,如图所示:
那么这个ThreadLocalMap对象的set方法又干了些什么呢?我们继续进去看。
我们可以看到。我们把数据重新处理,放入了一个Entry数组中。那么这个Entry数组又是什么呢?
我们来看一下Entry类的结构:
可以看到Entry内部结构像一个key-value键值对的Map一样,因此更新一下流程:
然后我再来观察Entry的数据类型:
最最最重点的来了。就是这个Entry的key这里是弱引用,该引用指向ThreadLocal的对象。what?弱引用?这是干什么用的?不要急,保持你的疑惑。我们先跟着上述步骤更新我们的流程图:
终于,到了这一步,和我们最经典的图相吻合了。这时候我们长出一口气,总算完啦!不!我说没完。还有最最关键的一步。
我们知道弱引用的特性是在一次GC后,与对象之间的联系断开。那么程序在运行一段时间,随便发生一次GC后,整个内存图是这样的。这才最后内存中数据的分布!
那有人又说?好家伙,你图都成这样了,我再通过ref.get()方法获取值还能获取到吗!稍安勿躁,这就带你继续看。
我们发现,诶当我们去get当前线程的ThreadLocal数据时,我们也是获取当前线程,再次委托给我们的ThreadLocalMap去查询。当执行到getEntry时,我们传入参数this,正是我们的当前对象的引用ref。
因此,程序就变为了去获取当前线程的TreadLocalMap的Entry的key为ref的value数据。也就是走的图中的2号路线。
有没有毛瑟顿开的感觉!这些总算可以收工了吧?当你准备长出一口气时,我说还没有!因为博主一开始就有一个疑惑。就是我Entry的key执行ref对象的引用断开时,我Entry中的key不会变为null么?答案我们继续揭晓。
弱引用解读
我们知道java中有强软弱虚4种引用,而弱引用的定义就是只要发生gc,那么引用链就会断开。我们来用以程序测试一下弱引用。
首先,我们先随意定义一个类测试类。
其次,我们使用弱引用引用这个类。我们测试以下程序在发生一次GC后,wrTest的结果是否为null。
此时我们看到,该对象的确已经为null了。此时,我们更换写法。
诶?问题来了。为什么这个弱引用在发生一次GC后,值依然可以获取到呢?是弱引用的引用链没有消失么?不,真相是我们此时的new Test()对象也恰巧被一个test强引用所指向,因此发生了GC也无法回收掉。这与我们ThreadLocal中,Entry的key断开与new ThreadLocal()的引用链,却依旧不为null的场景完全吻合。
我们得到结论:即使弱引用所指向的对象与弱引用断开引用链,但若是该对象有其他地方引用而导致无法回收,那么我的弱引用依旧可以通过断开前的连接地址去获取值。(也就是说引用的断开不会影响我们引用的寻址功能。引用的断开只会导致引用链断开导致对象被GC回收,但是!此时若有一个强引用引用着,那么弱引用就可以在无引用链的情况下继续访问该对象。(这里扩展一下。若对象的地址强制改变,弱引用将无法继续跟踪))。
举一个简单的案例:假设你买票上火车,找到了座位做了进去。但是记性很差的你,上了个厕所回来找不到自己的座位了。此时,列车员始终可以根据你的购票档案查到你的座位号。
到此为止,ThreadLocal的源码图解可以告一段落了。
为什么ThreadLocalMap中的key要设置成弱引用?
ThreadLocal的被回收的场景
首先,强调一下这个假设的前提是ThreadLocal的用法使用不到位导致的,不优雅的。为什么博主这么说呢?因为ThreadLocal为了可以拥有在每个线程直接独立创建副本的能力,我们通常会把它用public static final进行修饰。也就是说这个引用不出意外将永远不会消失。
有人会反驳说,虽然你这个引用用public static final进行修饰不会消失,但是线程会执行结束啊?如果仔细读了上述流程的读者应该已经很明确我们ThreadLocal获取值是根据当前线程的ThreadLocalMap获取的,如果当前线程结束,那么该线程的ThreadLocalMap对象会一起消失。对应的Entry也会一起消失。(后续还有讲解)
内存泄漏的原因
我们之前在讲解流程的时候,讲过ThreadMap中的Entry是弱引用。
那么此时,我们逆向思考ThreadLocalMap中Entry的key是强引用,那么当我们的ref出栈后,1号线断开后,Entry就会始终有一个2号引用指向new ThreadLocal()对象,导致该对象永远无法访问,也无法回收,导致内存泄漏。
为了避免这种尴尬,Entry的key与new ThreadLocal的对象设置为弱引用。(咱哥俩联系一次就得了,以后找你讨债没问题,你是死是活我管不着)。着实把该对象当成了工具人!
设置为弱引用后,经过一次GC内存模型如下:
此时,当ref出栈,new ThreadLoal孤立无援,唯有被回收的下场。到此,最常见的内存泄漏讲解完毕。
很多网上的博客,都是这么解析的。虽然光论结果来说都能说通,但是其实是本质对ThreadLocal并没有深刻的理解。
当步骤1断开后,步骤2再次经过垃圾回收断开,对象才被孤立无援被回收。此处我很自信的说:2其实在1断开之前就和对象彻底决裂分手再无瓜葛了!如果还没理解,就继续把我上述分析流程再看看。
Entry的key内存泄漏
我们之前看的博客说的最多的就是ThreadLocal对象的内存泄漏。然而其实我们发现Entry其实也有泄漏。如图,由于我们将ThreadLocal对象的成功回收,这些我们的key”终于”变为null了。但是我们的value依旧存在,因此这一组数据的value由于key为null的原因也无法访问导致内存泄漏。
呀!这可咋办,之前看的博客没人提过啊!别急,我们来看ThreadLocal是如何应对的。
Set优化
此时,当Entry的下标i对应的key值为null的话,说明key已经被回收了,那么直接把位置继续占用即可,反正key为null已经没用了。
Get优化
可以看到,get发现key为null的处理方式是直接从Entry中强行删除。
Remove方法
remove是我们主动触发,清理Entry的方式。和get方法底层调用的是同一个方法。可以加速我们泄漏的内存回收。因此,如果当栈中的引用变为null时,我们可以再次调用remove()方法,将ThreadLocalMap中的Entry进行清理。(更具时效性)
线程退出时优化
最后,当线程退出的时候,Thread类会进行清理操作。其中就包括清理ThreadLocalMap。
线程退出执行的exit()方法。
ThradLocal可以设置成局部变量,可以但没意义,而且有内存泄漏风险
内存泄漏讲了这么这么多!其实我们发现导致内存泄漏的原因就是这个ThreadLocal设置成了局部变量,导致ThreadLocal对象在线程结束前被回收。此时就会造成内存泄漏一直到线程结束才可以释放掉的风险。如果一定要这么写,那么一定记得在ThreadLocal对象回收时调用一下remove()方法及时释放内存。
另外,threadLocal如果设置成局部变量,那么同一个线程中的其他方法也无法获取当该对象。这样也就背离了ThreadLocal在同一个线程下,共享同一个变量的设计初衷了。核弹杀蚂蚁。
ThreadLocal的错误使用导致线程好像不安全了?
这个代码原本的意图是,每个线程的ThreadLocal对象分别执行一次数据的累加,理论上每个线程打印的值应该都是2。但结果却是5。
当ThreadLocal操作相同对象的时候,所有的操作都指向同一个实例。如果想让上面的程序正常运行,需要每一个ThreadLocal都持有一个新的实例。
所以这个线程不安全完全是因为使用者错误的使用,ThreadLocal绝对是线程安全的。
ThreadLocal的正确使用
之前讲的例子,都是基于错误的写法而画出的图:
对应的流程图是这样:
至于这么写为什么有问题,如果你还有问题,那说明上面的内容没有吃透,建议返回仔细再看。
正确的用法:
设置为全局变量,让所有线程共享方法,那么图就变为了: