java 并发(七)--- ThreadLocal

     文章部分图片来自参考资料

问题 :

• ThreadLocal 底层原理
• ThreadLocal 需要注意什么问题，造成问题的原因是什么，防护措施是什么

ThreadLocal 概述    

         ThreadLocal 线程本地变量 ，是一个工具，可以让多个线程保持一个变量的副本，那么每个线程可以访问自己内部的副本变量。

       

           ThreadLocal 结构图里面看到有两个内部类，一个 SuppliedThreadLocal , 一个ThreadLocalMap 。下面用一张图来说明线程使用的示意图。可以看到每个Thread 有个 ThreadLocalMap ，然后里面由hash值分列的的数组 Entry[] 。Entry 数据结构就是图中淡绿色框内所示。所以 ThreadLocal 里面放的 value 应该是放在Thread里面的。

ThreadLocal  源码分析

         ThreadLocal 下文简称 TL, TL最常见的方法就是 get 和 set 了。

public void set(T value) {
        Thread t = Thread.currentThread();
        ThreadLocalMap map = getMap(t);
        if (map != null)
            map.set(this, value);
        else
            createMap(t, value);
}

    public T get() {
        Thread t = Thread.currentThread();
        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;
            }
        }
        return setInitialValue();
    }

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

 ThreadLocal.ThreadLocalMap threadLocals = null;

         可以看到thread 内部中持有TL的内部类变量。我们来看一下 ThreadLocalMap, threadLocalMap 内部定义一个类，Entry 类。这是threadLocalMap  内的变量

ThreadLocalMap  类

static class ThreadLocalMap {
    /**
     * The initial capacity -- MUST be a power of two.
     */
    private static final int INITIAL_CAPACITY = 16;

    /**
     * The table, resized as necessary.
     * table.length MUST always be a power of two.
     */
    private Entry[] table;

    /**
     * The number of entries in the table.
     */
    private int size = 0;

    /**
     * The next size value at which to resize.
     */
    private int threshold; // Default to 0
}

 static class Entry extends WeakReference<ThreadLocal<?>> {
            /** The value associated with this ThreadLocal. */
            Object value;

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

         我们看到 TL 的set 方法实际就是调用了 ThreadLocalMap 的set 方法。

 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();

            	//找到相同的 key 
                if (k == key) {
                    e.value = value;
                    return;
                }

                //某个key失效
                if (k == null) {
                    replaceStaleEntry(key, value, i);
                    return;
                }
            }

           	//走到这里必定是退出了循环，即是遇到空的 entry ,直接放在空的地方，检查是否需要扩容，重新 hash 
            tab[i] = new Entry(key, value);
            int sz = ++size;
            if (!cleanSomeSlots(i, sz) && sz >= threshold)
                rehash();
}


  //   这个方法是替代某些失效的entry ,最终的值会放在 table[staleSlot]
  //  slotToExpunge 这个变量从名字上可以看出就是需要擦洗的 slot (指的是某个位置)
 private void replaceStaleEntry(ThreadLocal<?> key, Object value,
                                       int staleSlot) {
            Entry[] tab = table;
            int len = tab.length;
            Entry e;

            // Back up to check for prior stale entry in current run.
            // We clean out whole runs at a time to avoid continual
            // incremental rehashing due to garbage collector freeing
            // up refs in bunches (i.e., whenever the collector runs).
            //  向前找是否有失效节点，如果有做一下标记，即是为 slotToExpunge 赋值
            int slotToExpunge = staleSlot;
            for (int i = prevIndex(staleSlot, len);
                 (e = tab[i]) != null;
                 i = prevIndex(i, len))
                if (e.get() == null)
                    slotToExpunge = i;

            // Find either the key or trailing null slot of run, whichever
            // occurs first
            //  向后寻找是否有相同的 key
            for (int i = nextIndex(staleSlot, len);
                 (e = tab[i]) != null;
                 i = nextIndex(i, len)) {
                ThreadLocal<?> k = e.get();

                // If we find key, then we need to swap it
                // with the stale entry to maintain hash table order.
                // The newly stale slot, or any other stale slot
                // encountered above it, can then be sent to expungeStaleEntry
                // to remove or rehash all of the other entries in run.
            	//  找到相同的值，交换位置到 tab[staleSlot]
                if (k == key) {
                    e.value = value;

                    tab[i] = tab[staleSlot];
                    tab[staleSlot] = e;

                    // Start expunge at preceding stale entry if it exists
                    // 擦洗失效值
                    if (slotToExpunge == staleSlot)
                        slotToExpunge = i;
                    cleanSomeSlots(expungeStaleEntry(slotToExpunge), len);
                    return;
                }

                // If we didn't find stale entry on backward scan, the
                // first stale entry seen while scanning for key is the
                // first still present in the run.
                if (k == null && slotToExpunge == staleSlot)
                    slotToExpunge = i;
            }

            // If key not found, put new entry in stale slot
            //找不到值会放在 tab[staleSlot] ，即原来失效值的位置上
            tab[staleSlot].value = null;
            tab[staleSlot] = new Entry(key, value);

            // If there are any other stale entries in run, expunge them
            // 擦洗失效值
            if (slotToExpunge != staleSlot)
                cleanSomeSlots(expungeStaleEntry(slotToExpunge), len);
}

       

       

     可以看到我们在 set 的时候，TL内会检查是否存在失效值。也可以看到 ThreadLocalMap 的Hash 中解决冲突的方式只是简单的向下寻找空的位置，即线性探测，这样的效率比较低，所以建议 ：

         每个线程只存一个变量，这样的话所有的线程存放到map中的Key都是相同的ThreadLocal，如果一个线程要保存多个变量，就需要创建多个ThreadLocal，多个ThreadLocal放入Map中时会极大的增加Hash冲突的可能。

        下面看一下 get 方法，不难。

// ThreadLocalMap
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 getEntry(ThreadLocal<?> key) {
            int i = key.threadLocalHashCode & (table.length - 1);
            Entry e = table[i];
            if (e != null && e.get() == key)
                return e;
            else
            	//获取的时候出现失效的entry
                return getEntryAfterMiss(key, i, e);
        }


        // 往后找，失效的值擦洗掉，没有就返回 Null
        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;
        }

使用ThreadLocal内存失效问题分析

为什么使用弱引用

         我们来看一下weakReference 表示弱引用，java中有四种引用类型，强引用，弱引用，软引用，虚引用。

         在Java语言中, 当一个对象o被创建时, 它被放在Heap里. 当GC运行的时候, 如果发现没有任何引用指向o, o就会被回收以腾出内存空间. 也就是说, 一个对象被回收, 必须满足两个条件:

• 没有任何引用指向它

• GC被运行.

         

DemoA a=new DemoA();
DemoB b=new DemoB(a);

        假如有下面代码，如果我们增加一行代码来将a对象的引用设置为null，当一个对象不再被其他对象引用的时候，是会被GC回收的，但是对于这个场景来说，即时是a=null，也不可能被回收，因为DemoB依赖DemoA，这个时候是可能造成内存泄漏的。

DemoA a=new DemoA();
DemoB b=new DemoB(a);
a=null;

         通过弱引用，有两个方法可以避免这样的问题。

//方法1
DemoA a=new DemoA();
DemoB b=new DemoB(a);
a=null;
b=null;
//方法2
DemoA a=new DemoA();
WeakReference b=new WeakReference(a);
a=null;

        对于方法2来说，DemoA只是被弱引用依赖，假设垃圾收集器在某个时间点决定一个对象是弱可达的(weakly reachable)（也就是说当前指向它的全都是弱引用），这时垃圾收集器会清除所有指向该对象的弱引用，然后把这个弱可达对象标记为可终结(finalizable)的，这样它随后就会被回收。

       我们可以设想b就是ThreadLocal ，试想一下如果这里没有使用弱引用，意味着ThreadLocal的生命周期和线程是强绑定，只要线程没有销毁，那么ThreadLocal一直无法回收。而使用弱引用以后，当ThreadLocal被回收时，由于Entry的key是弱引用，不会影响ThreadLocal的回收防止内存泄漏，同时，在后续的源码分析中会看到，ThreadLocalMap本身的垃圾清理会用到这一个好处，方便对无效的Entry进行回收。

        所以使用了弱引用的原因是为了防止 ThreadLocal 对象没有被正确回收而导致的内存泄漏。

ThreadLocalMap 使用了弱引用会导致内存泄漏  

      ThreadLocalMap下文简称  TLM ，是存在Thread 中的，那么它的生存周期必定和线程的生命周期一样长的。

static class Entry extends WeakReference<ThreadLocal<?>> {
            /** The value associated with this ThreadLocal. */
            Object value;

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

         ThreadLocal在ThreadLocalMap中是以一个弱引用身份被Entry中的Key引用的，因此如果ThreadLocal没有外部强引用来引用它，那么ThreadLocal会在下次JVM垃圾收集时被回收。这个时候就会出现Entry中Key已经被回收，出现一个null Key的情况，外部读取ThreadLocalMap中的元素是无法通过null Key来找到Value的。因此如果当前线程的生命周期很长，一直存在，那么其内部的ThreadLocalMap对象也一直生存下来，这些null key就存在一条强引用链的关系一直存在：Thread --> ThreadLocalMap-->Entry-->Value，这条强引用链会导致Entry不会回收，Value也不会回收，但Entry中的Key却已经被回收的情况，造成内存泄漏。（出处）

        

         我们从源码中也可以看到在 get 和 set 等方法都有检查失效值的操作，同时当我们使用TL时，某个线程不再需要某个值的时候应该调用 remove 方法，下面代码中 e.clear() 这一句实际是调用了弱引用的 clear 方法，实现对对象的回收。

        private void remove(ThreadLocal<?> key) {
            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)]) {
                if (e.get() == key) {
                    e.clear();
                    expungeStaleEntry(i);
                    return;
                }
            }
        }

    /**
     * Clears this reference object.  Invoking this method will not cause this
     * object to be enqueued.
     *
     * <p> This method is invoked only by Java code; when the garbage collector
     * clears references it does so directly, without invoking this method.
     */
    public void clear() {
        this.referent = null;
    }

其实我们从源码分析可以看到，ThreadLocalMap是做了防护措施的

• 首先从ThreadLocal的直接索引位置(通过

  ThreadLocal.threadLocalHashCode & (len-1)运算得到)获取Entry e，如果e不为null并且key相同则返回e

• 如果e为null或者key不一致则向下一个位置查询，如果下一个位置的key和当前需要查询的key相等，则返回对应的Entry，否则，如果key值为null，则擦除该位置的Entry，否则继续向下一个位置查询

        由上面的分析，我们知道了ThreadLocal 使用了弱引用后还是会导致内存泄漏，而内存泄漏的原因是 ： ThreadLocalMap的生存周期和线程一样长，而不是使用弱引用导致的！！！         

Entry 的 Hash 值

         如何实现一个线程多个ThreadLocal对象，每一个ThreadLocal对象是如何区分的呢？ 

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

static class ThreadLocalMap {
     static class Entry extends WeakReference<ThreadLocal<?>> {

       /** The value associated with this ThreadLocal. */
        Object value;

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

     ThreadLocalMap(ThreadLocal<?> firstKey, Object firstValue) {
	   //构造一个Entry数组，并设置初始大小
           table = new Entry[INITIAL_CAPACITY];
           //计算Entry数据下标
           int i = firstKey.threadLocalHashCode & (INITIAL_CAPACITY - 1);
	   //将`firstValue`存入到指定的table下标中
           table[i] = new Entry(firstKey, firstValue);
           size = 1;//设置节点长度为1
           setThreshold(INITIAL_CAPACITY); //设置扩容的阈值
      }
//...省略部分代码
}

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);
}

        那为什么要使用到 0x61c88647 这个值呢？ 我们首先要明白一点，散列的目的是使数据分布更加均匀。那么这个数字的使用必定会达到这个目的。

魔数0x61c88647的选取和斐波那契散列有关，0x61c88647对应的十进制为1640531527。而斐波那契散列的乘数可以用 (long)((1L<<31)*(Math.sqrt(5)-1)); 如果把这个值给转为带符号的int，则会得到-1640531527。也就是说(long)((1L<<31)*(Math.sqrt(5)-1));得到的结果就是1640531527，也就是魔数0x61c88647

      

建议

• 将ThreadLocal变量定义成private static的，这样的话ThreadLocal的生命周期就更长，由于一直存在ThreadLocal的强引用，所以ThreadLocal也就不会被回收，也就能保证任何时候都能根据ThreadLocal的弱引用访问到Entry的value值，然后remove它，防止内存泄露

• 每次使用完ThreadLocal，都调用它的remove()方法，清除数据。

• 在线程池中使用ThreadLocal ，有可能会出现数据混淆的情况，原因是数据没及时清理，线程放回线程池中又被拿出来使用。

 

总结

• ThreadLocal 使用 弱引用的原因是为了处理非常大和生命周期非常长的线程，为了防止 ThreadLocal回收导致的内存泄漏，
  但是使用了弱引用也有可能导致内存泄漏，这次 ThreadLocal被回收了，但是value一直存活着，要是没有手动删除的话，
  依旧会导致内存泄漏，所以ThreadLocalMap 的 get ,set 中都有防护措施---检查ThreadLocal 为空的 Entry ,然后删除掉该
  Entry.
• 在使用完ThreadLocal，记得调用remove 方法。

参考资料 ：

• ThreadLocal-面试必问深度解析
• ThreadLocal内存泄漏真因探究
• 上面两篇文章必读！！
• JAVA高级架构 微信公众号的 “ThreadLocal的使用及原理分析”
• 从 ThreadLocal 的实现看散列算法