ThreadLocal源码解析(2)

在上一篇ThreadLocal源码解析(1)中我们分析了ThreadLocal、Thread以及ThreadLocalMap的关系, 这一篇我们继续分析ThreadLocalMap中的Entry类以及剖析一下ThreadLocal的内存泄漏问题

Entry类

先上代码, Entry这个类比较简单, 首先看一下Entry的构造函数, 我们可以得知Entry是由ThreadLocal和value组成的二元组, 或者可以直接说ThreadLocal是key, value就是那个value, 类似于其他Map中的结构

但是需要注意的是Entry这个类继承了WeakReference, 弱引用的泛型中传入的是ThreadLocal, 这说明了Entry的key(ThreadLocal)是弱引用。弱引用和强引用不同, 如果一个对象只存在弱引用的话, 那么会直接被垃圾回收

static class Entry extends WeakReference<ThreadLocal<?>> {
    Object value;

    Entry(ThreadLocal<?> k, Object v) {
        super(k);
        value = v;
    }
}

Entry中ThreadLocal的弱引用的作用是什么?

直接给答案: Entry中之所以设置ThreadLocal为弱引用, 是为了及时被垃圾回收

具体的流程是这样的, 如图所示, 假设我们在方法A中定义了一个ThreadLocal, 经过往ThreadLocal中设置值, 情况就变成了下图的样子, 现在ThreadLocal有两个引用, 一个是方法A中定义的ThreadLocal的强引用, 另一个是Entry中key的弱引用。 当方法A执行完退出线程栈的时候, 强引用释放, 此时只保留弱引用的ThreadLocal就会被回收, Entry中的key就会变为null

看到这里, 你可能会问了, 正常使用ThreadLocal谁会定义在方法中啊, 那不是扯吗? 先别急, 先跟着我的思路走

根据上面的描述, 你可能会有这样一个疑问, Entry中的key为null了, 但是value还存在啊, 还是在浪费空间啊。哈哈, 其实ThreadLocal的设计者早就想到了, 在ThreadLocal的get、set以及remove方法中均有对key为null的Entry的清理操作, 小伙伴们可以自己看源码找一下, 这里就不展开了

为什么ThreadLocal会存在内存泄漏问题

之前上面的例子是在方法中定义了ThreadLocal的变量, 而我们正常使用中大多是定义为static final的形式, 其实在阿里的代码规范中也有提到这一点。用static final来定义使用它主要是出于以下的考虑:

• 使用static 可以节省空间, 如果定义为static, 则多个线程中的ThreadLocalMap就可以使用相同的一个ThreadLocal作为key, 减少了ThreadLocal实例的个数
• final是为了防止实例被修改, 因为本身ThreadLocal的设计思想就是线程本地变量, 如果ThreadLocal的实例引用被修改了就会出现问题

好了, 我们看一下如果使用static final的形式定义ThreadLocal会存在什么问题?

从上图可以看出, static final修饰的强引用会一直存在, 导致ThreadLocal无法回收, 这里大家应该就明白了为什么存在内存泄漏问题了吧。

所以生产中使用ThreadLocal一定要记得手动释放奥~~