ThreadLocal详解

1 实现原理

        先看下ThreadLocal的简单使用：

继续看下set和get的实现逻辑可以得出其实现的原理如下：

        每个Thread内部维护着一个ThreadLocalMap，它是一个Map。这个映射表的Key是一个弱引用，指向的是ThreadLocal对象本身，Value存储的才是真正的线程变量Object。也就是说ThreadLocal本身并不真正存储线程的变量值，它只是一个工具，用来维护Thread内部的Map，帮助存和取。注意下图的虚线，它代表一个弱引用类型，而弱引用的生命周期只能存活到下次GC前。

2 ThreadLocal为什么会导致内存泄漏

        ThreadLocal对象在ThreadLocalMap中是以一个弱引用被Entry中的Key引用的，因此如果ThreadLocal没有外部强引用（比如ThreadLocal声明成static类型，或者ThreadLocal生命周期未结束还存在来自虚拟机栈的强引用）来引用它，那么ThreadLocal会在下次JVM垃圾收集时被回收。

这个时候就会出现Entry中Key已经被回收，出现一个null Key的情况，外部读取ThreadLocalMap中的元素是无法通过null Key来找到Value的。如果当前线程的生命周期很长（线程不结束Thread对象会一直存在），那么其内部的ThreadLocalMap对象也一直生存下来，这些null key就存在一条强引用链的关系一直存在：Thread --> ThreadLocalMap-->Entry-->Value，这条强引用链会导致Entry不会回收，Value也不会回收，但Entry中的Key却已经被回收的情况，造成内存泄漏。

JVM团队已经考虑到这样的情况，并做了一些措施来保证ThreadLocal尽量不会内存泄漏：在ThreadLocal的get()、set()、remove()方法调用的时候会清除掉线程ThreadLocalMap中所有Entry中Key为null的Value，并将整个Entry设置为null，利于下次内存回收。但这样也并不能保证ThreadLocal不会发生内存泄漏，例如：

使用static的ThreadLocal，延长了ThreadLocal的生命周期，可能导致的内存泄漏。分配使用了ThreadLocal又不再调用get()、set()、remove()方法，那么就会导致内存泄漏。

3 为什么使用弱引用？

官方文档的说法是这样：

To help deal with very large and long-lived usages, the hash table entries use WeakReferences for keys. 为了处理非常大和生命周期非常长的线程，哈希表使用弱引用作为 key。

        假设使用强引用，那么当引用的ThreadLocal的对象被回收之后，生命周期很长的情况下Thread依然存在，ThreadLocalMap还会持有ThreadLocal的强引用，如果没有手动删除，ThreadLocal不会被回收，导致Entry内存一直被占用，就会存在泄漏。

        如果使用弱引用，那么当引用的ThreadLocal的对象被回收之后，由于ThreadLocalMap持有ThreadLocal的弱引用，即使没有手动删除，ThreadLocal也会被回收。value在下一次ThreadLocalMap调用set,get，remove的时候会被清除。

        由于ThreadLocalMap的生命周期跟Thread一样长，如果都没有手动删除对应key，都会导致内存泄漏，但是使用弱引用可以多一层保障：弱引用ThreadLocal不会内存泄漏，对应的value在下一次ThreadLocalMap调用set,get,remove的时候会被清除。

        综合上面的分析，我们可以理解ThreadLocal内存泄漏的前因后果，那么怎么避免内存泄漏呢？每次使用完ThreadLocal，都调用它的remove()方法，清除数据。

4 ThreadLocal是线程安全的吗

        根据ThreadLocal的实现原理来看，ThreadLocal变量本身是线程隔离的，因此对ThreadLocal变量本身的赋值和读取操作各线程间是互不影响的，因此是线程安全的。但是其内部存储值的数据结构（如集合、数组、对象等）如果被错误地共享，则可能导致线程安全问题。