一张图解决ThreadLocal
一张图解决ThreadLocal
一、前言
年底梳理知识体系时，研究了一下ThreadLocal的源码，整理了一张核心图。
想着，都走到这一步了，那就写一篇深度解读的文章吧。看过我之前文章的小伙伴都知道，我写博客，就喜欢写点别人没写的。要么就写个结构比别人好的。什么都不行，那就别写了。自己留着看就好了。
然后发现了ThreadLocal源码解读与ThreadLocal可能引起的内存泄露这样的优秀文章（两篇文章合起来，就更完整了），它把我要说的，差不多都说了。
所以，我就决定从精简（一张图）与认知过程两方面，写一篇辅助学习ThreadLocal的文章。
二、核心图
不啰嗦，核心图直接贴上。
根据核心图，已经对ThreadLocal了然于心的小伙伴，可以拿着图片，溜了溜了。
还想听我谈谈，我对ThreadLocal认知过程的小伙伴，可以留下来看看。
三、认知过程
话说，那是一个夜黑风高的夜晚，我躺在。。。
咳咳咳。抱歉，串场了。
最早接触ThreadLocal的时候，是在看面试教程的时候。我听到讲师balabala讲了一通，最后我脑海给ThreadLocal的第一印象就是，一个确保线程安全的线程变量（同一个变量，但每个线程都独立）。这个印象伴随了我大半年，反正我在那大半年也没用过。。。
后来，在一次看技术文章的时候，又看到了一篇ThreadLocal的介绍。通篇看下来，这篇文章说的内容，除了我学过的，就是总结了一句ThreadLocal可以简单看成一个Map<Thread, Object>。当时的我，还欣喜若狂，我终于懂得ThreadLocal的原理了。
再后来，我在微信的技术公众号中，看到ThreadLocal的内存泄漏问题。那篇文章把这个问题说得非常严重，搞得好像这个问题导致了二战爆发那么严重。如果不懂这个问题，就不配参加面试，不配呼吸这个世界的美好空气。。。幸好当时没人知道，我不懂这个东西。然后我就趁着午休的时间，速度翻了翻这篇文章。看完之后，脑海中的印象就是，ThreadLocal中的map的key是WeakReference，可能被清除，导致对应的value内存泄漏。
在接下来的小半年里，我也曾奇怪，如果ThreadLocal是一个Map<Thread, Object>，那为什么一个线程可以有多个ThreadLocal变量呢？为什么设置ThreadLocal变量时，还需要设置范型类型呢？
直到在学习另一个课程时，讲师提到栈封闭-ThreadLocal，才知道之前的认识是错误的。其实每个线程都有一个Map<ThreadLocal, Object>，这也解释了我之前的两个问题。但是当时由于工作与课程比较紧，还是没有查看源码。终究还是与ThreadLocal隔层纱。
最近临近年底，整理自己的知识体系。这次打算好好整理整理，所以就仔细阅读了ThreadLocal的源码。也知道之所以每个线程都有一个Map<ThreadLocal, Object>，是因为Thread有一个ThreadLocalMap（ThreadLocal内部类）变量。进而总结出了上面的核心图。
四、总结
之所以提到ThreadLocal的认识过程，其实是想表达：
- 认识是螺旋前进的
- 如无必要，不要过于追求认识的深度
- 想法要周全，执行要坚决
第一条的意思是，我们对某个事物的认识，往往伴随着正确&错误之间的游走。但是认识是在不断加深，变得更加全面的。
至于第二条，如果一开始我就强求看源码，那一定是事倍功半的。那时候的我对范型，弱应用等都了解太浅，缺乏足够的基础，让我一窥ThreadLocal的全貌。具体的反面教材，就是当时刚入Java坑的我，强行撸Spring源码。。。樯橹灰飞烟灭啊。。。
第三条，在自己有想法的时候，需要周全想法。如果有了决策结果，就应该去坚决地贯彻它。
不得不说，温故而知新啊。
愿与诸君共进步。
