证明: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的get,set方法无法防止内存泄漏

所以一个线程可以用不同的ThreadLocal把不同的值存在这个线程独享的散列表的不同位置上。下面这些entry的key就是不同的ThreadLocal。当有外部的强引用 使用ThreadLocal的时候,这个ThreadLocal是有效的,但是如果强引用都置空,则只剩弱引用,GC在内存紧张的情况下,可能会把弱引用指向的对象回收掉。

1.ThreadLocal还有效

证明:ThreadLocal的get,set方法无法防止内存泄漏

2.ThreadLocal只剩下弱引用

证明:ThreadLocal的get,set方法无法防止内存泄漏

3.只剩弱引用,回收堆上对象

证明:ThreadLocal的get,set方法无法防止内存泄漏

这样的话,就没有路径可以访问这个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方法可以防止内存泄漏。

为了打破这一假设,模拟内存泄漏的情况,举以下极端的例子:

先规定:

证明:ThreadLocal的get,set方法无法防止内存泄漏

1.一开始都是有效的entry,并且每个entry的key通过散列算法后算出的位置都是自己所在的位置(都在自己的位置上的话之后的线性清扫中不会造成搬移,因为ThreadLocalMap的散列表用的是开放定址法,所以entry可能因为hash冲突而不在自己位置上)

要达成下面的效果,就要一直没有失效的entry出现,并且一直实现插入,也就是一直执行set方法

假设entry数组有32个槽位

证明:ThreadLocal的get,set方法无法防止内存泄漏

如果执行一次remove,把图中的某个entry无效化。

证明:ThreadLocal的get,set方法无法防止内存泄漏

下面是实现,因为每个entry都在自己的位置上,所以下图的if (e.get() == key) 会在第一个循环就成立,也就是remove会

执行e.clear() 来把弱引用置空,无效化。并且执行一次线性清扫后返回。

证明:ThreadLocal的get,set方法无法防止内存泄漏

关于线性清扫:

实现较长,分段看:

证明:ThreadLocal的get,set方法无法防止内存泄漏

上来就把要清扫的位置给置空了(灰色entry的槽位置空):

证明:ThreadLocal的get,set方法无法防止内存泄漏

接着看:

证明:ThreadLocal的get,set方法无法防止内存泄漏

向后遍历整个数组,直到遇到空槽为止,并且第一种情况 (k == null) 为真的情况下,会把无效entry置空,防止内存泄漏。

其实就是向后扫描,遇到无效的就顺带干掉,直到遇到空位置为止。

第二种情况是 : 遇到的entry是有效的,但是不是在自己原本的位置上,而是被hash冲突所迫而在其他位置上的,则把他们搬去

离原本位置最近的后边空槽上。这样在get的时候,会最快找到这个entry,减少开放定址法遍历数组的时间

证明:ThreadLocal的get,set方法无法防止内存泄漏

证明:ThreadLocal的get,set方法无法防止内存泄漏

最终的效果只是把我们remove的位置置为空槽。

同理,经过几次remove后,我们可以“挖出”下图的效果 证明:ThreadLocal的get,set方法无法防止内存泄漏

正巧,这时候有两个entry的key,也即是ThreadLocal的所有强应用被置空,于是这两个entry无效。

证明:ThreadLocal的get,set方法无法防止内存泄漏

如果之后只执行 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的使用槽数到达阈值则重散列(蓝色框)

证明:ThreadLocal的get,set方法无法防止内存泄漏 证明:ThreadLocal的get,set方法无法防止内存泄漏

我们重点关注情况2.

假设我们set的位置是下面所指处。

证明:ThreadLocal的get,set方法无法防止内存泄漏

我们接着上面的2分析,2要调用到replaceStaleEntry

再假设set进去的ThreadLocal在本数组中下面绿色位置

证明:ThreadLocal的get,set方法无法防止内存泄漏

证明:ThreadLocal的get,set方法无法防止内存泄漏

方法一开始是找到最靠前的无效entry,直到遇到空槽为止,当然可能会绕数组一圈绕回来

但是因为使用的槽数如果到达阈值,就会rehash,不可能所有槽都用完。所以会遇到空槽的。

表现在我们的例子中:

证明:ThreadLocal的get,set方法无法防止内存泄漏

因为没有找到,所以 slotToExpunge = staleSlot

也就是上图第二个灰色entry的位置。

接着向下看:

证明:ThreadLocal的get,set方法无法防止内存泄漏

我们关注 k == key 的情况,也就是 i 遍历图中绿色槽位的情况。 这种情况下会指向一次线性清扫,然后执行对数清扫。之后返回。

证明:ThreadLocal的get,set方法无法防止内存泄漏

证明:ThreadLocal的get,set方法无法防止内存泄漏

反应在图例中:

证明:ThreadLocal的get,set方法无法防止内存泄漏

从slotToExpunge位置开始,先进行一轮线性清扫:

同之前一样,一上来先把待清扫槽位置空(第二个灰色的entry的位置),之后遇到第二个灰色后面那个空位,所以停下来。

线性清扫返回空位的下标做为参数传给对数清扫。

证明:ThreadLocal的get,set方法无法防止内存泄漏

反应到图例:

证明:ThreadLocal的get,set方法无法防止内存泄漏

对数清扫:清扫次数 = log2(N) ,N是散列表大小,本例中是32,所以要清扫5次,每次清扫是通过调用线性清扫实现的。

并且只有遇到无效entry时才执行线性清扫。

证明:ThreadLocal的get,set方法无法防止内存泄漏

显然,五次扫描中都没有无效entry

证明:ThreadLocal的get,set方法无法防止内存泄漏

返回 removed (false);

cleanSomeSlots要返回,一直返回到replaceStaleEntry,并且继续返回,最后从set方法返回。

  证明:ThreadLocal的get,set方法无法防止内存泄漏

结果很明显,第一个灰色entry未被清除。

证明:ThreadLocal的get,set方法无法防止内存泄漏

结论:set方法的清扫程度不够深,set方法并不能防止内存泄漏。

get方法呢?

证明:ThreadLocal的get,set方法无法防止内存泄漏 证明:ThreadLocal的get,set方法无法防止内存泄漏

get 方法比较简单,在原本属于当前 key 的位置上找不到当前 key 的 entry 的话,就会根据开放定址法线性遍历找到 key 对应的 entry 。

顺便把路上无效的entry用线性清扫清除掉。

还是刚刚的极端例子:

证明:ThreadLocal的get,set方法无法防止内存泄漏

证明:ThreadLocal的get,set方法无法防止内存泄漏

证明:ThreadLocal的get,set方法无法防止内存泄漏

因为是直接取线性清扫开始的位置,所以 k = key 是 true,所以返回绿色entry。查找成功

证明:ThreadLocal的get,set方法无法防止内存泄漏

但是,第一个灰色entry仍然没有被清除。

什么办法可以保证万无一失呢???

答:每次置空一个ThreadLocal的所有强引用之后,都调用ThreadLocal的remove方法:

证明:ThreadLocal的get,set方法无法防止内存泄漏

e.clear是直接置空弱引用,这样当前这个entry就会无效

证明:ThreadLocal的get,set方法无法防止内存泄漏

之前说过,线性清扫会直接把第一个无效entry,也就是起点的entry槽位置空,以此达到 100 % 的回收效果。

证明:ThreadLocal的get,set方法无法防止内存泄漏

结论:

get,set两个方法都不能完全防止内存泄漏,还是每次用完ThreadLocal都勤奋的remove一下靠谱。

原文 

http://www.cnblogs.com/lqlqlq/p/13302901.html

本站部分文章源于互联网,本着传播知识、有益学习和研究的目的进行的转载,为网友免费提供。如有著作权人或出版方提出异议,本站将立即删除。如果您对文章转载有任何疑问请告之我们,以便我们及时纠正。

PS:推荐一个微信公众号: askHarries 或者qq群:474807195,里面会分享一些资深架构师录制的视频录像:有Spring,MyBatis,Netty源码分析,高并发、高性能、分布式、微服务架构的原理,JVM性能优化这些成为架构师必备的知识体系。还能领取免费的学习资源,目前受益良多

转载请注明原文出处:Harries Blog™ » 证明:ThreadLocal的get,set方法无法防止内存泄漏

赞 (0)
分享到:更多 ()

评论 0

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址