证明:ThreadLocal的get,set方法无法防止内存泄漏
先给出结论： get，set两个方法都不能完全防止内存泄漏，还是每次用完ThreadLocal都勤奋的remove一下靠谱。
前言：
看到有的博客说在把ThreadLocal的所有强引用置空前，调用 set 或 get 方法的话，则可以防止这个失去所有强引用的ThreadLocal对应的value内存泄漏。 但是文章作者一般没有接着向下讲为什么get，set 方法能防止内存泄漏。
本着刨根问底的精神，我们来看看原实现，验证一下get，set方法是否真的能防止内存泄漏。
先介绍一下内存布局：
每个Thread保存自己独占的ThreadLocalMap，ThreadLocalMap包含一个散列表（entry数组），散列表里 entry 继承WeakReference<ThreadLocal>，并且 entry 的 key 隐式等于ThreadLocal， value 则是显示用成员变量来存储。
所以一个线程可以用不同的ThreadLocal把不同的值存在这个线程独享的散列表的不同位置上。下面这些entry的key就是不同的ThreadLocal。当有外部的强引用 使用ThreadLocal的时候，这个ThreadLocal是有效的，但是如果强引用都置空，则只剩弱引用，GC在内存紧张的情况下，可能会把弱引用指向的对象回收掉。
1.ThreadLocal还有效
2.ThreadLocal只剩下弱引用
3.只剩弱引用，回收堆上对象
这样的话，就没有路径可以访问这个ThreadLocal了。
但是value还是通过ThreadLocalMap -> entry -> value -> 堆上大对象 的方式强应用着之前的value。这样导致这块内存无法被使用（如果没有其他强应用的话），也无法被回收。称内存泄漏。
于是ThreadLocalMap的设计者，想出了办法：
1.在ThreadLocal get，set 的时候顺带把散列表中的无效entry 置空，并且把这些entry 的 value也置空，以便value被回收，也就是执行清扫操作
2.在ThreadLocal remove 的时候把对应槽位上的 entry 置空，并且把这 个entry 的 value也置空，以便value被回收。顺便执行清扫操作。
get，set 方法真的能保证内存不泄露么？
这篇文章想讨论的问题是：
1.get，set方法的清扫程度是否足够彻底，以至于可以防止内存泄漏。
2.用什么方法才能保证内存不泄露
1如果成立，也即是保证如下场景内存不泄露：
使用多个 ThreadLocal，不是每次都使用 remove 方法，并且把一个ThreadLocal对应的所有强应用置空之前只调用过 get, set方法，调用get，set方法可以防止内存泄漏。
为了打破这一假设，模拟内存泄漏的情况，举以下极端的例子：
先规定：
1.一开始都是有效的entry，并且每个entry的key通过散列算法后算出的位置都是自己所在的位置（都在自己的位置上的话之后的线性清扫中不会造成搬移，因为ThreadLocalMap的散列表用的是开放定址法，所以entry可能因为hash冲突而不在自己位置上）
要达成下面的效果，就要一直没有失效的entry出现，并且一直实现插入，也就是一直执行set方法
假设entry数组有32个槽位
如果执行一次remove，把图中的某个entry无效化。
下面是实现，因为每个entry都在自己的位置上，所以下图的if (e.get() == key) 会在第一个循环就成立，也就是remove会
执行e.clear() 来把弱引用置空，无效化。并且执行一次线性清扫后返回。
关于线性清扫：
实现较长，分段看：
上来就把要清扫的位置给置空了（灰色entry的槽位置空）：
接着看：
向后遍历整个数组，直到遇到空槽为止，并且第一种情况 (k == null) 为真的情况下，会把无效entry置空，防止内存泄漏。
其实就是向后扫描，遇到无效的就顺带干掉，直到遇到空位置为止。
第二种情况是 ： 遇到的entry是有效的，但是不是在自己原本的位置上，而是被hash冲突所迫而在其他位置上的，则把他们搬去
离原本位置最近的后边空槽上。这样在get的时候，会最快找到这个entry，减少开放定址法遍历数组的时间。
最终的效果只是把我们remove的位置置为空槽。
同理，经过几次remove后，我们可以“挖出”下图的效果 
正巧，这时候有两个entry的key，也即是ThreadLocal的所有强应用被置空，于是这两个entry无效。
如果之后只执行 set 方法，是否会内存泄漏呢？是否任意调用set之后就保证内存不会泄漏了呢？
我们顺着 set 方法的逻辑看下去，set方法从当前要set的位置开始向后遍历，直到：
1.遇到 key 和我们当前 调用 set 的 ThreadLocal 相等的 entry，则只用直接把entry的value设置以下就好了，和
HashMap的 put(1, A); put(1, B); 中 A 被替换 成B 同理。（红色框）
2.遇到无效entry， 是我们关注的地方 。
3.遇到空槽，直接插入，并且尝试指数清扫，如果指数清扫不成功并且当前entry的使用槽数到达阈值则重散列（蓝色框）
我们重点关注情况2.
假设我们set的位置是下面所指处。
我们接着上面的2分析，2要调用到replaceStaleEntry
再假设set进去的ThreadLocal在本数组中下面绿色位置
方法一开始是找到最靠前的无效entry，直到遇到空槽为止，当然可能会绕数组一圈绕回来
但是因为使用的槽数如果到达阈值，就会rehash，不可能所有槽都用完。所以会遇到空槽的。
表现在我们的例子中：
因为没有找到，所以 slotToExpunge = staleSlot
也就是上图第二个灰色entry的位置。
接着向下看：
我们关注 k == key 的情况，也就是 i 遍历图中绿色槽位的情况。 这种情况下会指向一次线性清扫，然后执行对数清扫。之后返回。
反应在图例中：
从slotToExpunge位置开始，先进行一轮线性清扫：
同之前一样，一上来先把待清扫槽位置空（第二个灰色的entry的位置），之后遇到第二个灰色后面那个空位，所以停下来。
线性清扫返回空位的下标做为参数传给对数清扫。
反应到图例：
对数清扫：清扫次数 = log2（N） ，N是散列表大小，本例中是32，所以要清扫5次，每次清扫是通过调用线性清扫实现的。
并且只有遇到无效entry时才执行线性清扫。
显然，五次扫描中都没有无效entry
返回 removed (false);
cleanSomeSlots要返回，一直返回到replaceStaleEntry,并且继续返回，最后从set方法返回。
结果很明显，第一个灰色entry未被清除。
结论：set方法的清扫程度不够深，set方法并不能防止内存泄漏。
get方法呢？
get 方法比较简单，在原本属于当前 key 的位置上找不到当前 key 的 entry 的话，就会根据开放定址法线性遍历找到 key 对应的 entry 。
顺便把路上无效的entry用线性清扫清除掉。
还是刚刚的极端例子：
因为是直接取线性清扫开始的位置，所以 k = key 是 true，所以返回绿色entry。查找成功
但是，第一个灰色entry仍然没有被清除。
什么办法可以保证万无一失呢？？？
答：每次置空一个ThreadLocal的所有强引用之后，都调用ThreadLocal的remove方法：
e.clear是直接置空弱引用，这样当前这个entry就会无效
之前说过，线性清扫会直接把第一个无效entry，也就是起点的entry槽位置空，以此达到 100 % 的回收效果。
结论：
get，set两个方法都不能完全防止内存泄漏，还是每次用完ThreadLocal都勤奋的remove一下靠谱。
正文到此结束
热门推荐
相关文章
近期评论
-
文章和留言都翻到11页了 没有OOM
-
-
朋友，翻页到11页，及以后，会出现OOM，无法访问
-
-
搞个gitee的项目
-
-
版本号是多少，你可以下载哪个代码仓库，jdk选1.8 直接跑就行
-
-
-
Loading...
![[HBLOG]公众号](https://www.liuhaihua.cn/img/qrcode_gzh.jpg)
