ThreadLocal的使用以及底层原理

1.概述

在处理多线程并发的场景中，如果要保证线程安全，相信大家马上出现的想法就是锁机制，但是无论是乐观锁还是悲观锁，都会在并发冲突的时候对性能造成影响，那么有没有一种方法，可以彻底避免发生资源竞争呢？
答案就是ThreadLocal
从字面意思理解，ThreadLocal可以解释成是线程的局部变量，只允许当前线程访问，别的线程都访问不了，既然是线程私有的，那么肯定就不会发生竞争了。
因此ThreadLocal提供了一种与众不同的保证线程安全的方式，它不是在发生冲突的时候加锁，而是彻底杜绝了冲突的发生。

ThreadLocal的基本使用

创建一个ThreadLocal对象

private ThreadLocal<Integer> localInt = new ThreadLocal<>();

上述代码创建一个localInt变量，由于ThreadLocal是一个泛型类，这里指定了localInt的类型为整数。

下面展示了如果设置和获取这个变量的值：

public int setAndGet(){
    localInt.set(8);
    return localInt.get();
}

上述代码设置变量的值为8，接着取得这个值。
由于ThreadLocal里设置的值，只有当前线程自己看得见，这意味着你不可能通过其他线程为它初始化值。为了弥补这一点，ThreadLocal提供了一个withInitial()方法统一初始化所有线程的ThreadLocal的值：

private ThreadLocal<Integer> localInt = ThreadLocal.withInitial(() -> 6);

上述代码将ThreadLocal对象设置为6，但是此时对全体线程都是可见的。

ThreadLocal的实现原理

ThreadLocal变量只在单个线程可见，但是它是如何做到这一点的呢，我们首先看一下它的get()方法：

public T get() {
    //获得当前线程
    Thread t = Thread.currentThread();
    //每个线程 都有一个自己的ThreadLocalMap，
    //ThreadLocalMap里就保存着所有的ThreadLocal变量
    ThreadLocalMap map = getMap(t);
    if (map != null) {
        //ThreadLocalMap的key就是当前ThreadLocal对象实例，
        //多个ThreadLocal变量都是放在这个map中的
        ThreadLocalMap.Entry e = map.getEntry(this);
        if (e != null) {
            @SuppressWarnings("unchecked")
            //从map里取出来的值就是我们需要的这个ThreadLocal变量
            T result = (T)e.value;
            return result;
        }
    }
    // 如果map没有初始化，那么在这里初始化一下
    return setInitialValue();
}

可以看到ThreadLocal变量就是保存在当前线程的ThreadLocalMap中的，这个map对象存储的也是key-value对象，key就是ThreadLocal实例，value就是对应的值，这个map就是Thread对象中的threadLocals字段。如下：

ThreadLocal.ThreadLocalMap threadLocals = null;

ThreadLocal.ThreadLocalMap是一个比较特殊的Map，它的每个Entry的key都是一个弱引用：

static class Entry extends WeakReference<ThreadLocal<?>> {
    /** The value associated with this ThreadLocal. */
    Object value;
    //key就是一个弱引用
    Entry(ThreadLocal<?> k, Object v) {
        super(k);
        value = v;
    }
}

这样设计的好处是，如果这个变量不再被其他对象使用时，可以自动回收这个ThreadLocal对象，避免可能的内存泄露（注意，Entry中的value，依然是强引用，如何回收，见下文分解）。

ThreadLocal的内存泄露问题

虽然ThreadLocalMap中的key是弱引用，当不存在外部强引用的时候，就会自动被回收，但是Entry中的value依然是强引用。这个value的引用链条如下：

可以看到，**只有当Thread被回收时，这个value才有被回收的机会，否则，只要线程不退出，value总是会存在一个强引用。**但是，要求每个Thread都会退出，是一个极其苛刻的要求，对于线程池来说，大部分线程会一直存在在系统的整个生命周期内(线程复用)，那样的话，就会造成value对象出现泄漏的可能。处理的方法是，在ThreadLocalMap进行set(),get(),remove()的时候，都会进行清理：
以getEntry()为例：

private Entry getEntry(ThreadLocal<?> key) {
	//定位到key对应的位置i
    int i = key.threadLocalHashCode & (table.length - 1);
    Entry e = table[i];
    if (e != null && e.get() == key)
        //如果找到key，直接返回
        return e;
    else
        //如果找不到，就会尝试清理，如果你总是访问存在的key，那么这个清理永远不会进来
        return getEntryAfterMiss(key, i, e);
}

然后我们来看一下getEntryAfterMiss()是如何清理的：

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

    while (e != null) {
        // 整个e是entry ，也就是一个弱引用
        ThreadLocal<?> k = e.get();
        //如果找到了，就返回
        if (k == key)
            return e;
        if (k == null)
            //如果key为null，说明弱引用已经被回收了
            //那么就要在这里回收里面的value了
            expungeStaleEntry(i);
        else
            //如果key不是要找的那个，那说明有hash冲突，这里是处理冲突，找下一个entry
            i = nextIndex(i, len);
        e = tab[i];
    }
    return null;
}

真正用来回收value的是expungeStaleEntry()方法，在remove()和set()方法中，都会直接或者间接调用到这个方法进行value的清理：
从这里可以看到，ThreadLocal为了避免内存泄露，也算是花了一番大心思。不仅使用了弱引用维护key，还会在每个操作上检查key是否被回收，进而再回收value。
但是从上面的代码也可以看出ThreadLocal并不能保证100%不会发生内存泄漏。
比如，很不幸的，你的get()方法总是访问固定几个一直存在的ThreadLocal，那么清理动作就不会执行，如果你没有机会调用set()和remove()，那么这个内存泄漏依然会发生。
因此我们要养成一个良好的习惯，如果我们不需要使用某个ThreadLocal变量，我们应该主动调用remove()方法，这样对整个系统是有好处的。

ThreadLocal中的Hash冲突处理

ThreadLocalMap作为一个HashMap和java.util.HashMap的实现是不同的。对于java.util.HashMap使用的是链表法来处理冲突：

但是，对于ThreadLocalMap，它使用的是简单的线性探测法，如果发生了元素冲突，那么就使用下一个槽位存放：

具体来说，整个的set流程如下图：

简单总结一下就是：
首先根据hash出来的值定位到对应的位置i，然后判断这个位置是否被占用，如果没有，那么直接使用即可。
如果当前位置已经被占用了，就代表发生了哈希冲突，这又分成几种情况：
1）判断get得到的ThreadLocal变量是否和位置i的key相等，如果相等就代表需要更新value，我们就需要将原先的value值覆盖
2）get得到的ThreadLocal为null，代表对应的key已经被回收了，那么这时候就要调用replaceStableEntry()方法清理value
3）get得到的ThreadLocal变量和位置i的key不一致，那么就向下寻找，直到找到合适的位置。

可以继承的ThreadLocal—InheritableThreadLocal

在实际开发过程中，我们可能会遇到这么一种场景。主线程开了一个子线程，但是我们希望在子线程中可以访问主线程中的ThreadLocal对象，也就是说有些数据需要进行父子线程间的传递。比如像这样：

public static void main(String[] args) {
    ThreadLocal threadLocal = new ThreadLocal();
    IntStream.range(0,10).forEach(i -> {
        //每个线程的序列号，希望在子线程中能够拿到
        threadLocal.set(i);
        //这里来了一个子线程，我们希望可以访问上面的threadLocal
        new Thread(() -> {
            System.out.println(Thread.currentThread().getName() + ":" + threadLocal.get());
        }).start();
        try {
            Thread.sleep(1000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    });
}

执行上述代码，结果为：

Thread-0:null
Thread-1:null
Thread-2:null
Thread-3:null

因为在子线程中，是没有threadLocal的。如果我们希望子线可以看到父线程的ThreadLocal，那么就可以使用InheritableThreadLocal。顾名思义，这就是一个支持线程间父子继承的ThreadLocal，将上述代码中的threadLocal使用InheritableThreadLocal：

InheritableThreadLocal threadLocal = new InheritableThreadLocal();

执行结果就变成：

Thread-0:0
Thread-1:1
Thread-2:2
Thread-3:3
Thread-4:4

可以看到，每个线程都可以访问到从父进程传递过来的一个数据。虽然InheritableThreadLocal看起来挺方便的，但是依然要注意以下几点：

变量的传递是发生在线程创建的时候，如果不是新建线程，而是用了线程池里的线程，就不灵了
变量的赋值就是从主线程的map复制到子线程，它们的value是同一个对象，如果这个对象本身不是线程安全的，那么就会有线程安全问题

Reference

掘金社区——敖丙