深入理解ThreadLocal

存储结构

threadLocal存储于Thread类上的ThreadLocalMap类型的threadLocals中。

从ThreadLocalMap的名字上可以看出其结构类似于HashMap，它也是使用key-value结构的Entry数组table来存储ThreadLocal和值。

但区别在于Entry继承于WeakReference，key使用弱引用，其好处在于当threadlocal没有强引用时，key将在下一次gc中被回收，但仅仅key被回收，value不会被回收，这就是ThreadLocal会导致内存泄漏的原因，但ThreadLocal也有一些机制去处理这种情况，后续会说。

还有一种区别在于解决hash冲突的方式，HashMap是使用数组+链表，即拉链法来解决的，而ThreadLocalMap使用线性探测法，即当前位置冲突，探测下一个地址是否冲突，不冲突插入。

set过程

首先是获取thread上的ThreadLocalMap

	public void set(T value) {
        //1.获取当前线程
        Thread t = Thread.currentThread();
       	//2.获取线程上的ThreadLocalMap
        ThreadLocalMap map = getMap(t);
        if (map != null)
            //3.1.存在调用ThreadLocalMap的set方法
            map.set(this, value);
        else
            //3.2.不存在初始化ThreadLocalMap
            createMap(t, value);
    }

	ThreadLocalMap getMap(Thread t) {
        return t.threadLocals;
    }

	void createMap(Thread t, T firstValue) {
        t.threadLocals = new ThreadLocalMap(this, firstValue);
    }

获取到ThreadLocalMap之后，将threadlocal和value封装为Entry保存到数组中。

	private void set(ThreadLocal key, Object value) {
            Entry[] tab = table;
            int len = tab.length;
        	//1.通过threadlocal的threadLocalHashCode获取到存放位置
            int i = key.threadLocalHashCode & (len-1);

            for (Entry e = tab[i];
                 e != null;
                 e = tab[i = nextIndex(i, len)]) {
                ThreadLocal k = e.get();
				//2.1.当前存放位置key相等，替换值
                if (k == key) {
                    e.value = value;
                    return;
                }
				//2.2.当前存放位置key已经被gc回收，替换当前位置的entry
                if (k == null) {
                    replaceStaleEntry(key, value, i);
                    return;
                }
                //2.3.当前位置已存放别的threadlocal，线性探测下一个位置
            }
			
        	//3.当前位置为空，存放
            tab[i] = new Entry(key, value);
            int sz = ++size;
        	//4.回收key已经gc的entry，然后判断是否扩容
            if (!cleanSomeSlots(i, sz) && sz >= threshold)
                rehash();
        }

我们看下threadLocalHashCode的获取。

	private final int threadLocalHashCode = nextHashCode();

    private static AtomicInteger nextHashCode =
        new AtomicInteger();

    private static final int HASH_INCREMENT = 0x61c88647;

    private static int nextHashCode() {
        return nextHashCode.getAndAdd(HASH_INCREMENT);
    }

每次实例化ThreadLocal的时候都会从nextHashCode获取，而每次获取都会加上`0x61c88647，HASH_INCREMENT的注释是比起连续的自增序列能使threadlocal在ThreadLocalMap分布更加均匀。

for (int i = 0; i < 16; i++) {
     System.out.println(0x61c88647 * i & 15);
}

运行这段代码，我们确实可以发现16个值随机均匀的分布在0-15之间，正好符合threadlocalMap上面的16个entry大小数组。

我们知道threadLocalMap在到达threshold的时候会发生扩容，这时ThreadLocal会进行rehash重新存放，我们将上面的i改为32会发现还是均匀的分布在0-32之间，那么一直不会发生hash冲突。那么到底什么时候会发生hash冲突？

前面我们提到Entry的key为弱引用，在没有强引用下，下次gc将会回收，在set方法中我们可以看replaceStaleEntry和cleanSomeSlots方法，这里就是回收key被回收后的Entry节点。

我们先说回hash冲突，假设在size达到threshold之前，有些key已经被回收，那么在新建了16个threadlocal之后，将出现一个再次填充到第一个threadlocal位置的threadlocal，这时就会导致hash冲突。

我们假设ThreadLocalMap大小为4，阈值为4，如下图所示：

ThreadLocalMap填入ThreadLocal4时，ThreadLocal2、ThreadLocal3已经没有强引用触发gc，那么Entry2、Entry3的key将会为null。

这时将会触发cleanSomeSlots，回收Entry2、Entry3。

这时我们才填入ThreadLocal5，这时就会和Entry1发生hash冲突，探测下一个位置填入。

以上就是整个set过程中hash冲突发生的情况和ThreadLocalMap如何处理的过程。

下面我们再看下replaceStaleEntry和cleanSomeSlots如何回收Entry的。

我们追踪replaceStaleEntry和cleanSomeSlots会发现其都调用expungeStaleEntry方法。

private int expungeStaleEntry(int staleSlot) {
            Entry[] tab = table;
            int len = tab.length;
			
    		//释放当前位置的过期Entry
            tab[staleSlot].value = null;
            tab[staleSlot] = null;
            size--;

            Entry e;
            int i;
    		//从当前位置开始探测下一个，如果已经过期则清除，如果未过期重新rehash插入。
            for (i = nextIndex(staleSlot, len);
                 (e = tab[i]) != null;
                 i = nextIndex(i, len)) {
                ThreadLocal k = e.get();
                
                if (k == null) {
                    //已经gc清除Entry
                    e.value = null;
                    tab[i] = null;
                    size--;
                } else {
                    //Threadlocal还没被gc，进行rehash
                    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;
        }

这个清除过期Entry的逻辑，我们可以看到在get和remove等方法中进行了调用，这也是ThreadLocal解决内存泄漏的机制。

总结

1. ThreadLocal使用类似HashMap的结构进行存储，区别在于其key使用弱引用，还有解决hash冲突使用线性探测法。
2. ThreadLocal发生hash冲突的情况，只在ThreadLocalMap达到阈值之前已经发生弱引用被gc的情况下，否则ThreadLocalMap只会进行扩容，极少发生hash冲突。
3. ThreadLocal解决因为弱引用被gc导致Entry节点还存在的内存泄漏，使用在set、get、remove等方法中进行回收弱引用被gc的Entry节点。因此唯一存在内存泄漏的情况是在弱引用被gc之后从未调过set、get、remove等方法，对此阿里规范中要求，对不在使用ThreadLocal要调用remove方法。

子线程继承父线程的ThreadLocal——InheritableThreadLocal

InheritableThreadLocal会让子线程拥有父线程的InheritableThreadLocal，其原理就在于Thread在创建的时候会获取当前线程的inheritableThreadLocals，然后使用创建自己的inheritableThreadLocals会将当前的inheritableThreadLocals复制。

Netty对ThreadLocal的优化——FastThreadLocal

存储结构

FastThreadLocal对应的map为InternalThreadLocalMap，他抛弃了ThreadLocalMap的结构，使用Object数组进行存储。

其中头部存放的是Set集合的FastThreadLocal，而其他部分存放的是FastThreadLocal的值。FastThreadLocal上有一个index变量存放其值在Object数组中的位置。

而FastThreadLocal index的值是全局自增的。

优化点

set仅仅只需要将FastThreadLocal的值存放到Object上对应的位置，同时将FastThreadLocal存放到Object头部的set集合中

get操作也只需要拿到FastThreadLocal的index，去object上获取值

remove操作也只需要拿到FastThreadLocal的index，将object对应的值置为unset，同时从object头部的set集合移除FastThreadLocal。

这样一来不需要处理hash冲突和清除过期的节点，但由于index是一直自增的，会导致Object上无效的位置无法重复使用，Object一直增大，相当于用空间换时间。

还有FastThreadLocal的内存泄漏问题解决在于同样需要手动调用FastThreadLocal的remove方法，当Netty提供更方便的操作，使用FastThreadLocalRunnable对Runnable进行封装，其在run方法中调用FastThreadLocal的removeAll方法进行清除。

ThreadLocal在线程池中使用的问题

ThreadLocal销毁问题

由于线程池中的线程在使用完，不会进行销毁，只是重新放入线程池中，如果线程在使用完不对ThreadLocal进行remove，那么这会导致下次使用这个线程时获取到上次使用的ThreadLocal。

Spring中大量使用ThreadLocal，例如RequestContextHolder使用THreadLocal存放Request和Respons，Spring对它处理就是使用RequestContextFilter在逻辑处理完成之后调用remove方法。

ThreadLocal传输问题

如果ThreadLocal要在线程池中传输，我想到的是对Runnable进行包装，在创建的时候拷贝一份ThreadLocal的值，在run方法中重新设置回去ThreadLocal中。

阿里的TransmittableThreadLocal对其的处理就是如此做的。

ThreadLocal在Hystrix中传输问题

Hystrix的处理有两种，一种线程池，一种信号量。

ThreadLocal在Hystrix中传输问题也就是线程池中传输的问题，安照上面的解决方案，我们也只需要对Runnable和Callable进行封装。

Hystrix提供HystrixPlugin让我们定制化自己的HystrixConcurrencyStrategy，HystrixConcurrencyStrategy提供对Callable进行包装的方法wrapCallable，那么我们只需要在这里对Callable进行包装即可。