• 深入理解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进行包装即可。

  • 相关阅读:
    LeetCode91 Decode Ways
    LeetCode93 Restore IP Addresses
    LeetCode92 Reverse Linked List II
    LeetCode90 Subsets II
    LeetCode89 Gray Code
    最长公共子序列及其引申问题
    constexpr:编译期与运行期之间的神秘关键字
    I/O模型: 阻塞、非阻塞、I/O复用、同步、异步
    LeetCode86 Partition List
    maven 安装 过程
  • 原文地址:https://www.cnblogs.com/wuweishuo/p/13362761.html
Copyright © 2020-2023  润新知