一张图解决ThreadLocal

WPF 之路由事件和附加事件(六)

一张图解决ThreadLocal

一、前言

年底梳理知识体系时,研究了一下ThreadLocal的源码,整理了一张核心图。
想着,都走到这一步了,那就写一篇深度解读的文章吧。看过我之前文章的小伙伴都知道,我写博客,就喜欢写点别人没写的。要么就写个结构比别人好的。什么都不行,那就别写了。自己留着看就好了。
然后发现了ThreadLocal源码解读ThreadLocal可能引起的内存泄露这样的优秀文章(两篇文章合起来,就更完整了),它把我要说的,差不多都说了。
所以,我就决定从精简(一张图)与认知过程两方面,写一篇辅助学习ThreadLocal的文章。

二、核心图

不啰嗦,核心图直接贴上。

根据核心图,已经对ThreadLocal了然于心的小伙伴,可以拿着图片,溜了溜了。
还想听我谈谈,我对ThreadLocal认知过程的小伙伴,可以留下来看看。

三、认知过程

话说,那是一个夜黑风高的夜晚,我躺在。。。
咳咳咳。抱歉,串场了。
最早接触ThreadLocal的时候,是在看面试教程的时候。我听到讲师balabala讲了一通,最后我脑海给ThreadLocal的第一印象就是,一个确保线程安全的线程变量(同一个变量,但每个线程都独立)。这个印象伴随了我大半年,反正我在那大半年也没用过。。。

后来,在一次看技术文章的时候,又看到了一篇ThreadLocal的介绍。通篇看下来,这篇文章说的内容,除了我学过的,就是总结了一句ThreadLocal可以简单看成一个Map<Thread, Object>。当时的我,还欣喜若狂,我终于懂得ThreadLocal的原理了。

再后来,我在微信的技术公众号中,看到ThreadLocal的内存泄漏问题。那篇文章把这个问题说得非常严重,搞得好像这个问题导致了二战爆发那么严重。如果不懂这个问题,就不配参加面试,不配呼吸这个世界的美好空气。。。幸好当时没人知道,我不懂这个东西。然后我就趁着午休的时间,速度翻了翻这篇文章。看完之后,脑海中的印象就是,ThreadLocal中的map的key是WeakReference,可能被清除,导致对应的value内存泄漏

再记一次 应用服务器 CPU 暴高事故分析

在接下来的小半年里,我也曾奇怪,如果ThreadLocal是一个Map<Thread, Object>,那为什么一个线程可以有多个ThreadLocal变量呢?为什么设置ThreadLocal变量时,还需要设置范型类型呢?

直到在学习另一个课程时,讲师提到栈封闭-ThreadLocal,才知道之前的认识是错误的。其实每个线程都有一个Map<ThreadLocal, Object>,这也解释了我之前的两个问题。但是当时由于工作与课程比较紧,还是没有查看源码。终究还是与ThreadLocal隔层纱。

最近临近年底,整理自己的知识体系。这次打算好好整理整理,所以就仔细阅读了ThreadLocal的源码。也知道之所以每个线程都有一个Map<ThreadLocal, Object>,是因为Thread有一个ThreadLocalMap(ThreadLocal内部类)变量。进而总结出了上面的核心图。

四、总结

之所以提到ThreadLocal的认识过程,其实是想表达:

  • 认识是螺旋前进的
  • 如无必要,不要过于追求认识的深度
  • 想法要周全,执行要坚决

第一条的意思是,我们对某个事物的认识,往往伴随着正确&错误之间的游走。但是认识是在不断加深,变得更加全面的。
至于第二条,如果一开始我就强求看源码,那一定是事倍功半的。那时候的我对范型,弱应用等都了解太浅,缺乏足够的基础,让我一窥ThreadLocal的全貌。具体的反面教材,就是当时刚入Java坑的我,强行撸Spring源码。。。樯橹灰飞烟灭啊。。。
第三条,在自己有想法的时候,需要周全想法。如果有了决策结果,就应该去坚决地贯彻它。

不得不说,温故而知新啊。

愿与诸君共进步。

参考

JVM调优参数、方法、工具以及案例总结

相关推荐

发表评论

路人甲

网友评论(0)