java基础-ThreadLocal

来聊一下ThreadLocal的实现原理和它的内存泄漏问题

首先来看一个官方示例，这里构造了一个ThreadId类，其作用是在每个线程中保存各自的id，此id全局唯一，通过get可以获取id。

    private static class ThreadId {
        // Atomic integer containing the next thread ID to be assigned
        private static final AtomicInteger nextId = new AtomicInteger(1);
        // Thread local variable containing each thread's ID
        private static final ThreadLocal<Integer> threadId = new ThreadLocal<Integer>() {
            @Override
            protected Integer initialValue() {
                return nextId.getAndIncrement();
            }
        };
        // Returns the current thread's unique ID, assigning it if necessary
        public static int get() {
            return threadId.get();
        }
    }

ThreadLocal的构造器是一个空函数，new一个ThreadLocal实例时，唯一的操作就是对threadLocalHashCode的初始化，很明显这是一个hash值，猜测后续会用到map了。

private final int threadLocalHashCode = nextHashCode();

再来看调用get时，发生了什么

/**
     * Returns the value in the current thread's copy of this
     * thread-local variable.  If the variable has no value for the
     * current thread, it is first initialized to the value returned
     * by an invocation of the {@link #initialValue} method.
     *
     * @return the current thread's value of this thread-local
     */
    public T get() {
        Thread t = Thread.currentThread();
        //Thread中有一个ThreadLocalMap类型的实例字段，获得当前线程的threadLocalMap，其实就是返回t.threadLocals
        ThreadLocalMap map = getMap(t);
        if (map != null) {
            //以当前ThreadLocal实例为key，获取entry
            ThreadLocalMap.Entry e = map.getEntry(this);
            if (e != null) {
                @SuppressWarnings("unchecked")
                //得到entry中的value
                T result = (T)e.value;
                return result;
            }
        }
        //如果当前线程的threadLocalMap为null，或者当前threadLocal还未插入threadLocalMap，则进行相应初始化工作，无非就是初始化map、调用自定义的initialValue方法、将initialValue返回值包装成entry插入map
        return setInitialValue(); 
    }

看一下map的构造

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

            Entry(ThreadLocal<?> k, Object v) {
                //注意，这里key被包装成了一个WeakReference
                super(k);
                value = v;
            }
        }
        ......
        private Entry[] table;
        ......
        private Entry getEntry(ThreadLocal<?> key) {
            //threadLocalHashCode在ThreadLocal初始化时就已生成，全局唯一。这里
            int i = key.threadLocalHashCode & (table.length - 1);
            Entry e = table[i];
            if (e != null && e.get() == key)//e.get()即从WeakReference中取得threadLocal
                return e;
            else
                //有意思，一般的hash表都是使用一个链式结构来解决hash冲突，而这里当hash冲突时进行线性探测
                return getEntryAfterMiss(key, i, e);
        }
        ......
    }

问题来了，为什么entry中的key要包装成WeakReference呢？

设想，当我们不再需要threadLocal了，以前例来说就是置ThreadId中类变量threadId为null（假设threadId不是final，也没有被其他引用），而Thread类中的threadLocalMap中仍然持有threadId的引用，这就会产生内存泄漏。将threadLocal包装成WeakReference作为key存储，当threadId为null时，该threadLocal在gc时就会被回收，但此时value还在，ThreadLocal会在进行其他操作时删除key为null的value。这确实存在一种内存泄漏隐患，如果之后不在进行ThreadLocal操作，就真释放不掉value了。通常我们需要被声明为ThreadLocal的变量，在运行期间都是不期望它被回收的，所以我们通常会将其声明为static final，如果有回收的需求，也请使用ThreadLocal的remove进行显示释放。