锁定老帖子 主题:ThreadLocal的误解
精华帖 (0) :: 良好帖 (2) :: 新手帖 (0) :: 隐藏帖 (6)
|
|
---|---|
作者 | 正文 |
发表时间:2011-05-25
最后修改:2011-05-26
1. 就是当线程回收时,该线程绑定的变量不能被自动的回收,因为变量存储在ThreadLocal里,必须显式的去回收。如果此变量存储在线程里,那么线程回收时,这个变量没有被其他引用指向的话,它便随着线程一起回收。 2. 另外不这样做还有一个好处:如果Map在ThreadLocal里,那你必须得考虑线程同步访问这个Map,但是这确实没有必要,因为线程访问自己的变量,和其他线程没有直接的关系,所以把Map放在线程里,就不需要做同步的处理,这样即加快了访问的速度。 其实实现不是这样的:每个线程都包含一个ThreadLocal.ThreadLocalMap变量threadLocals(延迟创建的),这个映射(Map)目的就是为每个线程存储关联到使用到的不同ThreadLocal的变量,这个很好理解,因为,一个线程可能使用到多个不同的ThreadLocal对象,每一个ThreadLocal对象的值都被认为是不同的。于是,每次调用ThreadLocal的get()方法,其实就是获取当前线程(Thread.currentThread()),然后从threadLocals映射里,根据ThreadLocal对象,找出其关联的拷贝,这个值便是当前线程的,隔离于其他线程的值。 我们知道,ThreadLocal.ThreadLocalMap映射使用的键是被WeakReference包装的ThreadLocal对象,如果ThreadLocal对象没有其他强引用和软引用指向时,该线程也不会继续持有ThreadLocal对象,因为根据JVM规范,它会被垃圾回收器下次回收时销毁,这一定程度避免了内存泄露,但不表示不会出现内存泄露,关于ThreadLocal引起的内存泄露,特别是导致ClassLoader不能被回收,网上有很多文章都在讨论。在Java 1.5开始,加入了remove()方法,这样我们可以显式的调用此方法,释放内存,所以使用ThreadLocal要特别注意内存泄露的问题。 看来大家对ThreadLocal内存泄露的原因有点误解,其导致Classloader内存泄露的原因在这篇博文写的很清楚了Classloader leaks:,我在这里补充一下,jvm规范下的classloader能被回收的条件是,所有该classloader产生的所有对象都被回收了:我们知道,对象有一个隐式的引用指向它的类型class对象,而class对象有个隐式的引用指向它的classloader,所以如果有一个对象不回收,那么可能导致整个classloader不能够被回收。为什么是可能?这个是jvm规范规定的规范,但是实现并不尽相同,sun的hotspot目前版本是不会对还有不能回收对象的classloader做回收的,但是其他的jvm实现,比如Jrocket,ibm的jvm可能会产生回收那些无用的class对象,但目前没有看到源码,只能从现象猜测。线程池产生泄漏的一个原因主要可能是对线程重用产生的,这点读者有条件可以去测试。 特此申明一下,我的书籍http://redhat.iteye.com/admin/blogs/1007884关于4.2.3章节出现了纰漏,当我意识到错误时,花了1-2周来查看此问题,下载了sun jdk1.5版本,1.6版本,1.3版本,1.2版本,以及IBM的jdk代码进行比较,这个纰漏的申明在http://redhat.iteye.com/blog/1057991里,自己置顶,这个理解错误的原因是读取别人(老外)写的博文错误引起的,希望大家能够多读代码,谢谢! 声明:ITeye文章版权属于作者,受法律保护。没有作者书面许可不得转载。
推荐链接
|
|
返回顶楼 | |
发表时间:2011-05-25
没错,
我遇到过一种情况,当使用threadlocal的时候由于线程不关闭,结果内存越加越多,造成了内存泄露,最后只好在完成某步骤后,手动remove。 |
|
返回顶楼 | |
发表时间:2011-05-25
嗯,在使用线程池情况下,用完threadlocal一定要remove().
|
|
返回顶楼 | |
发表时间:2011-05-25
我也存在这样的误解,学习了
|
|
返回顶楼 | |
发表时间:2011-05-26
学习了,看了以后还是少用ThreadLocal,自己管理
|
|
返回顶楼 | |
发表时间:2011-05-26
对的,特别是在使用线程池时,如果A任务执行完成后没有显示的remove()的话,当另外一个任务B也使用该线程时,就会把A的信息带到B中,会出现很多莫名其妙的问题。所以一般是try {} finally{ remove() }块来操作。
|
|
返回顶楼 | |
发表时间:2011-05-26
obullxl 写道 对的,特别是在使用线程池时,如果A任务执行完成后没有显示的remove()的话,当另外一个任务B也使用该线程时,就会把A的信息带到B中,会出现很多莫名其妙的问题。所以一般是try {} finally{ remove() }块来操作。 恩,看我最后新添加的部分。 |
|
返回顶楼 | |
发表时间:2011-05-26
object_object 写道 学习了,看了以后还是少用ThreadLocal,自己管理 恩,看我最后新添加的部分。 |
|
返回顶楼 | |
发表时间:2011-05-26
kingkan 写道 嗯,在使用线程池情况下,用完threadlocal一定要remove(). 恩,看我最后新添加的部分。 |
|
返回顶楼 | |
发表时间:2011-05-27
最后修改:2011-05-27
LZ 写道 每次调用ThreadLocal的get()方法,其实就是获取当前线程(Thread.currentThread()),然后从threadLocals映射里,根据ThreadLocal对象,找出其关联的拷贝,这个值便是当前线程的,隔离于其他线程的值。"
这样的话,那其实我们调用ThreadLocal.set()存入的object实际是放在thread中的(thread.threadLocals这个映身射中),而这个map的key是TreadLocal对像,value是存入的object? 是这个意思吗.. |
|
返回顶楼 | |