ThreadLocal简析

基本原理&使用场景

在多线程的并发访问的场景，除了使用锁来控制不同线程对临界区的访问，来避免竞争，还有另外一种方式，就是ThreadLocal.
ThreadLocal中持有的数据只有当前线程可以访问，其他线程访问不了，这样就避免了线程竞争。

基本使用

下面是一个简单的threadLocal使用的例子，展示了ThreadLocal在多线程场景中的基本使用。

public class ThreadLocalDemo {

    private static final ThreadLocal<Integer> threadLocalFruit = new ThreadLocal<>();

    private static final ThreadLocal<Integer> threadLocalVegetable = new ThreadLocal<>();

    public static void main(String[] args) {
        new Thread(new ThreadLocalTestThread("农人A", 3, 5)).start();
        new Thread(new ThreadLocalTestThread("农人B", 7, 9)).start();
        LockSupport.park();
    }

    static void say(String words, Object... params) {
        System.out.println(MessageFormat.format(words, params));
    }

    static class ThreadLocalTestThread implements Runnable {

        private String name;

        private int fruitNum;

        private int vegetableNum;

        private Random random = new Random();

        public ThreadLocalTestThread(String name, int fruitNum, int vegetableNum) {
            this.name = name;
            this.fruitNum = fruitNum;
            this.vegetableNum = vegetableNum;

        }

        @Override
        public void run() {
            while (true) {
                say("{0} 收获 {1} 个水果", name, fruitNum);
                threadLocalFruit.set(fruitNum);
                say("{0} 收获 {1} 个蔬菜", name, vegetableNum);
                threadLocalVegetable.set(vegetableNum);
                try {
                    TimeUnit.MICROSECONDS.sleep(random.nextInt(500));
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
                say("{0} 用掉 {1} 个水果", name, threadLocalFruit.get());
                say("{0} 用掉 {1} 个蔬菜", name, threadLocalVegetable.get());
            }
        }
    }
}

程序的执行结果如下，从执行结果来看，【农人1】线程对threadlocal的set仅【农人1】可见，【农人2】线程对threadlocal的set仅【农人2】可见，两者对threadloacl的get/set互不影响。
农人B 收获 7 个水果
农人A 收获 3 个水果
农人B 收获 9 个蔬菜
农人A 收获 5 个蔬菜
农人B 用掉 7 个水果
农人B 用掉 9 个蔬菜
农人A 用掉 3 个水果
农人B 收获 7 个水果
农人A 用掉 5 个蔬菜
农人B 收获 9 个蔬菜
农人A 收获 3 个水果
农人A 收获 5 个蔬菜
农人B 用掉 7 个水果
农人B 用掉 9 个蔬菜
农人A 用掉 3 个水果
农人B 收获 7 个水果
农人A 用掉 5 个蔬菜
农人B 收获 9 个蔬菜
农人A 收获 3 个水果
农人A 收获 5 个蔬菜

原理介绍

这么神奇的特性是怎么做到的呢？先看ThreadLocal的get方法源码.
从get方法的源代码来看，从threadlocal获取数据的时候，是从当前线程对象的ThreadLocalMap中获取的，所以获取到的数据是线程所特有的，不会被其他线程修改。

   public T get() {
        Thread t = Thread.currentThread();
        //每个线程都有自己的ThreadLocalMap
        //ThreadLocalMap保存threadlocal中的数据
        ThreadLocalMap map = getMap(t);
        if (map != null) {
            ThreadLocalMap.Entry e = map.getEntry(this);
            if (e != null) {
                @SuppressWarnings("unchecked")
                T result = (T)e.value;
                return result;
            }
        }
        //如果当前线程的ThreadLocalMap为空,则初始化ThreadLocalMap,
        //并将initialValue方法的返回值放入到ThreadLocalMap中。
        return setInitialValue();
    }
    
   ThreadLocalMap getMap(Thread t) {
        return t.threadLocals;
    }  

从下面的代码来看, ThreadLocalMap的key是一个弱引用，弱应用关联的对象内存在jvm gc的时候会被回收掉，可以避免key导致的内存泄露的问题，但value仍然是强引用，当key被回收之后，value就获取不到了，可能导致内存泄露。既然这样，为什么key要使用弱引用呢？详见【ThreadLocal内存泄露风险分析】

static class ThreadLocalMap {

        /**
         * The entries in this hash map extend WeakReference, using
         * its main ref field as the key (which is always a
         * ThreadLocal object).  Note that null keys (i.e. entry.get()
         * == null) mean that the key is no longer referenced, so the
         * entry can be expunged from table.  Such entries are referred to
         * as "stale entries" in the code that follows.
         */
        static class Entry extends WeakReference<ThreadLocal<?>> {
            /** The value associated with this ThreadLocal. */
            Object value;

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

ThreadLocal内存泄露风险分析

上面提到，既然弱引用的key被回收掉之后会导致value的内存泄露，那为什么key仍然要使用弱应用呢？当ThreadLocal对象没有强应用时，它们需要被清理掉，如果key是强引用，当引用threadLocal的对象都被回收掉时，因为key是强引用，还指向threadLocal，导致threadlocal无法被回收掉。从下面的引用关系图能比较直观的看到这个问题。

既然可能会造成内存泄露，那怎么解决这个问题呢。ThreadLocal给出的解决方案是在get/set的时候，会调用expungeStaleEntry去清理key=null的value和entry。

 private void set(ThreadLocal<?> key, Object value) {

            // We don't use a fast path as with get() because it is at
            // least as common to use set() to create new entries as
            // it is to replace existing ones, in which case, a fast
            // path would fail more often than not.

            Entry[] tab = table;
            int len = tab.length;
            int i = key.threadLocalHashCode & (len-1);

            for (Entry e = tab[i];
                 e != null;
                 e = tab[i = nextIndex(i, len)]) {
                ThreadLocal<?> k = e.get();

                if (k == key) {
                    e.value = value;
                    return;
                }
                //这里k为null，则执行value、entry的清理动作
                if (k == null) {
                    replaceStaleEntry(key, value, i);
                    return;
                }
            }

            tab[i] = new Entry(key, value);
            int sz = ++size;
            if (!cleanSomeSlots(i, sz) && sz >= threshold)
                rehash();
        

数据结构&算法

ThreadLocal的核心数据结构就是ThreadLocalMap，核心的代码如下：
这里会即将k为null的value也设置为null，然后将entry也设置为null，这样gc就可以回收掉了。然后对于k不为null的entry使用了高德斯算法（俗称洗牌算法）来重排，保证table中的元素随机分布，尽量避免hash冲突。
此外，从set方法源码也知，ThreadLocalMap 解决hash冲突使用的是开放地址法，就是一直在数组中寻找null的位置放入当前数据。解决hash冲突另一个比较有名的算法是链式地址法，HashMap就是经典案例，只不过java8之后，hashMap做了改进改为使用红黑树了。

  private Entry getEntry(ThreadLocal<?> key) {
            int i = key.threadLocalHashCode & (table.length - 1);
            Entry e = table[i];
            if (e != null && e.get() == key)
                return e;
            else
                return getEntryAfterMiss(key, i, e);
  }

 private Entry getEntryAfterMiss(ThreadLocal<?> key, int i, Entry e) {
            Entry[] tab = table;
            int len = tab.length;

            while (e != null) {
                ThreadLocal<?> k = e.get();
                if (k == key)
                    return e;
                if (k == null)
                    expungeStaleEntry(i);
                else
                    i = nextIndex(i, len);
                e = tab[i];
            }
            return null;
 }

private int expungeStaleEntry(int staleSlot) {
            Entry[] tab = table;
            int len = tab.length;

            // expunge entry at staleSlot
            tab[staleSlot].value = null;
            tab[staleSlot] = null;
            size--;

            // Rehash until we encounter null
            Entry e;
            int i;
            for (i = nextIndex(staleSlot, len);
                 (e = tab[i]) != null;
                 i = nextIndex(i, len)) {
                ThreadLocal<?> k = e.get();
                if (k == null) {
                    e.value = null;
                    tab[i] = null;
                    size--;
                } else {
                    int h = k.threadLocalHashCode & (len - 1);
                    if (h != i) {
                        tab[i] = null;
                        while (tab[h] != null)
                            h = nextIndex(h, len);
                        tab[h] = e;
                    }
                }
            }
            return i;
        }

其他

1、为避免threadlocal造成的内存泄露，要在最后调用remove方法。
2、正常情况，当Thread执行完会被销毁，Thread指向的threadLocalMap就会变为垃圾，里面的entry也就会被回收掉。
3、发生内存泄露的场景一般是在线程池的场景，当线程场景存活，key是弱引用被回收掉之后，key变成null，value的值还在，就可能出现内存泄露
4、在线程池的场景，如果在最后没有做remove，还可能会导致ThreadLocal里的数据被二次改写，造成多线程修改同个ThreadLocal的假象，其实是相同的线程对象被复用后，二次修改原线程对象ThreadLocal数据的问题。