深入理解ThreadLocal

存储结构

深入理解ThreadLocal_第1张图片

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,如下图所示:

深入理解ThreadLocal_第2张图片

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

深入理解ThreadLocal_第3张图片

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

深入理解ThreadLocal_第4张图片

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

深入理解ThreadLocal_第5张图片

以上就是整个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进行包装即可。

你可能感兴趣的:(深入理解ThreadLocal)