关于ThreadLocal中弱引用,以及其垃圾回收的两个问题

1.ThreadLocalMap.Entry中的key为什么不会被错误清理?
    一个对象在只有弱引用指向它时,垃圾回收一旦运行,就会被回收,但是ThreadLocal对象除了在Entry中有弱引用(它的key),还在业务代码中会被引用(否则也没必要创建它了不是),而业务代码中的引用一般都是强引用,所以对象如果在业务代码中还有引用,那么即使它被弱引用指向,垃圾回收时也不会被清理。
    
2.既然有remove方法可以清理这个Entry,为什么还需要弱引用?

    remove方法确实可以解决垃圾问题,但是它只有在你调用时才会起作用(: 你在不用一个map时会去remove其中的元素吗)。而一旦用户忘记调用该方法,(且假如ThreadLocalMap.Entry中的key是强引用的话 ),与天地(所在线程)同寿的ThreadLocalMap中就会一直存在这么一个钉子户,占据内存使之不能被正确回收,这种情况就可以称为内存泄漏了。
    
    假如这个线程是个可复用线程,且它要做的每一次任务都会向ThreadLocalMap中放值,那这个垃圾堆起来可不是开玩笑的,轻则系统卡顿,重则oom。
    
    而当前的做法是,使用弱引用,即使用户忘记调用remove方法,这个ThreadLocal对象在不用时也会被回收,一旦回收,任何对ThreadLocalMap的get和remove操作都会触发对持有无效key的Entry的清理。这样的话,即使你粗心大意,最多也只会在下一次垃圾回收,以及当前线程下一次操作它的ThreadLocalMap之前,允许这个Entry占一会内存。时机一到,expungeStaleEntry方法这个剃刀和gc这个推土机和配合起来,就会让滥竽充数的无用Entry消失于无形。

上一篇:ubuntu 多系统设置默认系统的系统


下一篇:数据结构队列的设计 (单向链表的应用)