ThreadLocal的实现与内存泄漏问题

一、ThreadLocal的实现

1.1 ThreadLocal存储数据吗？

ThreadLocal本身并不存储数据，每一个Thread的内部都维护着一个ThreadLocalMap，数据存储在这个ThreadLocalMap中。它的作用是操作维护这个ThreadLocalMap。

public class Thread implements Runnable {

    ThreadLocal.ThreadLocalMap threadLocals = null;
}

这也是为什么线程获取的都是自己线程的数据的原因，因为数据就存储在每个线程的内部中。

1.2 为什么key是ThreadLocal？

准确来说使用的是ThreadLocal对象在线程工作内存中的变量副本。
数据是存储在ThreadLocalMap中的，在线程运行的过程中，有可能会使用多个ThreadLocal，所以存储到ThreadLocalMap中用ThreadLocal对象为key，这样get的时候也不需要传key值了。

1.3 ThreadLocalMap的数据结构是什么？

ThreadLocalMap并没有继承Map，里面维护着一个hash表，会将key和value封装成一个Entry对象，根据ThreadLocal的hashCode与数组长度计算出下标，散列在这个hash表上。

Entry对象继承了WeakReference，对ThreadLocal弱引用作为key，弱引用的对象在 GC 时会被回收。

 static class Entry extends WeakReference<ThreadLocal<?>> {
            /** The value associated with this ThreadLocal. */
            Object value;

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

二、为什么会内存泄漏

内存泄漏： 简单来说，就是不再需要的资源因为强引用没有被gc回收掉，一直积压。

上一节说到对ThreadLocal弱引用作为key，如果ThreadLocal没有外部强引用的话，gc的时候肯定会被回收掉。这样就会出现key为null的Entry对象，我们无法正常访问key为null的Entry对象的value，如果当前线程的生存周期比较久，就会导致一直存在Entry对象对value的强引用。

ThreadLocalMap中也加上了一些防护措施，在ThreadLocal的get(),set(),remove()的时候都会清除线程ThreadLocalMap里所有key为null的value。

那为什么还会出现内存泄漏？我认为原因有以下几种：

• ThreadLocalMap的生命周期跟Thread一样长。
• set()了很多，但之后不再使用这个ThreadLocal了。
• key有外部不使用的强引用。

弱引用只是多一层保障，为了避免内存泄漏，使用完最好手动remove()。