证明: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，减少开放定址法遍历数组的时间。

 

 因为每个entry都在自己的位置上，并且没有遇到无效的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不在自己的原本位置上，上面的情况是可以得到的。因为假如绿色本来散列到的位置上有元素，那么将会向后线性扫描，发现空位，插入绿色元素，然后向后线性清扫是向后清扫，并且遇到空槽停下。

所以不会影响绿色entry

 

 

 

 

 

 方法一开始是找到最靠前的无效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一下靠谱。