最近学习了秒杀系统,做一些必要的笔记,一来是对自己学习的知识的巩固,二来对有同样问题的人有参考作用
一 ThreadLocal是什么?有哪些用途?
- 总结
所以有那么一句总结:ThreadLocal是线程Thread中属性threadLocals的管理者。也就是说我们对于ThreadLocal的get, set,remove的操作结果都是针对当前线程Thread实例的threadLocals存,取,删除操作。 - 举例
(1) 每个人都一张银行卡。
(2)每个人每张卡都有一定的余额。
(3)每个人获取银行卡余额都必须通过该银行的管理系统。
(4)每个人都只能获取自己卡持有的余额信息,他人的不可访问。
映射到我们要说的ThreadLocal:
(1)card类似于Thread。
(2)card余额属性,卡号属性等类似于Treadlocal内部属性集合threadLocals。
(3)cardManager类似于ThreadLocal管理类。
总结:cardManager通过验证Card的信息取到Card某个属性的值 - 应用场景
其实我们无意间已经时时刻刻在使用ThreadLocal提供的便利,如果说多数据源的切换你比较陌生,那么spring提供的声明式事务就再熟悉不过了,我们在研发过程中无时无刻不在使用,而spring声明式事务的重要实现基础就是ThreadLocal,只不过大家没有去深入研究spring声明式事务的实现机制。后面有机会我会给大家介绍spring声明式事务的原理及实现机制。
原来ThreadLocal这么强大,但应用开发者使用较少,同时有些研发人员对于ThreadLocal内存泄漏,等潜在问题,不敢试用,恐怕这是对于ThreadLocal最大的误解,后面我们将会仔细分析,只要按照正确使用方式,就没什么问题。如果ThreadLocal存在问题,岂不是spring声明式事务是我们程序最大的潜在危险吗?
二 ThreadLocal如何使用
为了更直观的体会ThreadLocal的使用我们假设如下场景:
1.我们给每个线程生成一个ID。
2.一旦设置,线程生命周期内不可变化。
3.容器活动期间不可以生成重复的ID
我们创建一个ThreadLocal管理类:
测试程序如下:我们同一个线程不断get,测试id是否变化,同时测试完成后我们就将其释放掉。
在主程序中我们开启多个线程测试不通线程之间是否会影响:
不出意外我们的结果为:
结果:确实是不同线程间ThreadLocal的id不同,相同线程ThreadLocal的id相同。
结论:ThreadLocal与线程是一一对应的,且是线程安全的。
三 ThreadLocal原理
- ThreadLocal类结构及方法解析:
上图可知:ThreadLocal三个方法get, set , remove以及内部类`ThreadLocalMap。 - ThreadLocal及Thread之间的关系:
从这张图我们可以直观的看到Thread中属性threadLocals,作为一个特殊的Map,它的key值就是我们ThreadLocal实例,而value值这是我们设置的值。 - ThreadLocal的操作过程:
我们以get方法为例:
其中getMap(t)返回的就上当前线程的threadlocals,如下图,然后根据当前ThreadLocal实例对象作为key获取ThreadLocalMap中的value,如果首次进来这调用setInitialValue()
set的过程也类似:
四 ThreadLocal使用有哪些坑及注意事项
经常在网上看到骇人听闻的标题,ThreadLocal导致内存泄漏,这通常让一些刚开始对ThreadLocal理解不透彻的开发者,不敢贸然使用。越不用,越陌生。这样就让我们错失了更好的实现方案,所以敢于引入新技术,敢于踩坑,才能不断进步。
我们来看下为什么说ThreadLocal会引起内存泄漏,什么场景下会导致内存泄漏?
Memory overflow:内存溢出,没有足够的内存提供申请者使用。
Memory leak:内存泄漏,程序申请内存后,无法释放已申请的内存空间,内存泄漏的堆积终将导致内存溢出。
显然是TreadLocal在不规范使用的情况下导致了内存没有释放。
红框里我们看到了一个特殊的类WeakReference,同样这个类,应用开发者也同样很少使用,这里简单介绍下吧
既然WeakReference在下一次gc即将被回收,那么我们的程序为什么没有出问题呢?
1. 所以我们测试下弱引用的回收机制:
这一种存在强引用不会被回收。
这里没有强引用将会被回收。
上面演示了弱引用的回收情况,下面我们看下ThreadLocal的弱引用回收情况。
2. ThreadLocal的弱引用回收情况
如上图所示,我们在作为key的ThreadLocal对象没有外部强引用,下一次gc必将产生key值为null的数据,若线程没有及时结束必然出现,一条强引用链
Threadref–>Thread–>ThreadLocalMap–>Entry,所以这将导致内存泄漏。
3. 所以我们总结了使用ThreadLocal时会发生内存泄漏的前提条件:
a.ThreadLocal引用被设置为null,且后面没有set,get,remove操作。
b.线程一直运行,不停止。(线程池)
c.触发了垃圾回收。(Minor GC或Full GC)
解决方法:
我们看到ThreadLocal出现内存泄漏条件还是很苛刻的,所以我们只要破坏其中一个条件就可以避免内存泄漏,单但为了更好的避免这种情况的发生我们使用ThreadLocal时遵守以下两个小原则:
a.ThreadLocal申明为private static final。
Private与final 尽可能不让他人修改变更引用,
Static 表示为类属性,只有在程序结束才会被回收。
b.ThreadLocal使用后务必调用remove方法。
最简单有效的方法是使用后将其移除。
五 总结
如有错误恳请指正,如有侵权请联系我删除
参考文章:https://blog.csdn.net/zzg1229059735/article/details/82715741