java 并发--- ThreadLocal

Posted 2021-01-29 float123

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

问题 :

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

ThreadLocal 概述    

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

       

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

 

ThreadLocal  源码分析

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

  1 public void set(T value) {
  2         Thread t = Thread.currentThread();
  3         ThreadLocalMap map = getMap(t);
  4         if (map != null)
  5             map.set(this, value);
  6         else
  7             createMap(t, value);
  8 }

  1     public T get() {
  2         Thread t = Thread.currentThread();
  3         ThreadLocalMap map = getMap(t);
  4         if (map != null) {
  5             ThreadLocalMap.Entry e = map.getEntry(this);
  6             if (e != null) {
  7                 @SuppressWarnings("unchecked")
  8                 T result = (T)e.value;
  9                 return result;
 10             }
 11         }
 12         return setInitialValue();
 13     }

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

 

  1  ThreadLocal.ThreadLocalMap threadLocals = null;

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

ThreadLocalMap  类

  1 static class ThreadLocalMap {
  2     /**
  3      * The initial capacity -- MUST be a power of two.
  4      */
  5     private static final int INITIAL_CAPACITY = 16;
  6 
  7     /**
  8      * The table, resized as necessary.
  9      * table.length MUST always be a power of two.
 10      */
 11     private Entry[] table;
 12 
 13     /**
 14      * The number of entries in the table.
 15      */
 16     private int size = 0;
 17 
 18     /**
 19      * The next size value at which to resize.
 20      */
 21     private int threshold; // Default to 0
 22 }
 23 

  1  static class Entry extends WeakReference<ThreadLocal<?>> {
  2             /** The value associated with this ThreadLocal. */
  3             Object value;
  4 
  5             Entry(ThreadLocal<?> k, Object v) {
  6                 super(k);
  7                 value = v;
  8             }
  9 }

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

  1  private void set(ThreadLocal<?> key, Object value) {
  2 
  3             // We don\'t use a fast path as with get() because it is at
  4             // least as common to use set() to create new entries as
  5             // it is to replace existing ones, in which case, a fast
  6             // path would fail more often than not.
  7 
  8             Entry[] tab = table;
  9             int len = tab.length;
 10             int i = key.threadLocalHashCode & (len-1);
 11 
 12             for (Entry e = tab[i];
 13                  e != null;
 14                  e = tab[i = nextIndex(i, len)]) {
 15                 ThreadLocal<?> k = e.get();
 16 
 17             	//找到相同的 key 
 18                 if (k == key) {
 19                     e.value = value;
 20                     return;
 21                 }
 22 
 23                 //某个key失效
 24                 if (k == null) {
 25                     replaceStaleEntry(key, value, i);
 26                     return;
 27                 }
 28             }
 29 
 30            	//走到这里必定是退出了循环，即是遇到空的 entry ,直接放在空的地方，检查是否需要扩容，重新 hash 
 31             tab[i] = new Entry(key, value);
 32             int sz = ++size;
 33             if (!cleanSomeSlots(i, sz) && sz >= threshold)
 34                 rehash();
 35 }
 36 
 37 
 38   //   这个方法是替代某些失效的entry ,最终的值会放在 table[staleSlot]
 39   //  slotToExpunge 这个变量从名字上可以看出就是需要擦洗的 slot (指的是某个位置)
 40  private void replaceStaleEntry(ThreadLocal<?> key, Object value,
 41                                        int staleSlot) {
 42             Entry[] tab = table;
 43             int len = tab.length;
 44             Entry e;
 45 
 46             // Back up to check for prior stale entry in current run.
 47             // We clean out whole runs at a time to avoid continual
 48             // incremental rehashing due to garbage collector freeing
 49             // up refs in bunches (i.e., whenever the collector runs).
 50             //  向前找是否有失效节点，如果有做一下标记，即是为 slotToExpunge 赋值
 51             int slotToExpunge = staleSlot;
 52             for (int i = prevIndex(staleSlot, len);
 53                  (e = tab[i]) != null;
 54                  i = prevIndex(i, len))
 55                 if (e.get() == null)
 56                     slotToExpunge = i;
 57 
 58             // Find either the key or trailing null slot of run, whichever
 59             // occurs first
 60             //  向后寻找是否有相同的 key
 61             for (int i = nextIndex(staleSlot, len);
 62                  (e = tab[i]) != null;
 63                  i = nextIndex(i, len)) {
 64                 ThreadLocal<?> k = e.get();
 65 
 66                 // If we find key, then we need to swap it
 67                 // with the stale entry to maintain hash table order.
 68                 // The newly stale slot, or any other stale slot
 69                 // encountered above it, can then be sent to expungeStaleEntry
 70                 // to remove or rehash all of the other entries in run.
 71             	//  找到相同的值，交换位置到 tab[staleSlot]
 72                 if (k == key) {
 73                     e.value = value;
 74 
 75                     tab[i] = tab[staleSlot];
 76                     tab[staleSlot] = e;
 77 
 78                     // Start expunge at preceding stale entry if it exists
 79                     // 擦洗失效值
 80                     if (slotToExpunge == staleSlot)
 81                         slotToExpunge = i;
 82                     cleanSomeSlots(expungeStaleEntry(slotToExpunge), len);
 83                     return;
 84                 }
 85 
 86                 // If we didn\'t find stale entry on backward scan, the
 87                 // first stale entry seen while scanning for key is the
 88                 // first still present in the run.
 89                 if (k == null && slotToExpunge == staleSlot)
 90                     slotToExpunge = i;
 91             }
 92 
 93             // If key not found, put new entry in stale slot
 94             //找不到值会放在 tab[staleSlot] ，即原来失效值的位置上
 95             tab[staleSlot].value = null;
 96             tab[staleSlot] = new Entry(key, value);
 97 
 98             // If there are any other stale entries in run, expunge them
 99             // 擦洗失效值
100             if (slotToExpunge != staleSlot)
101                 cleanSomeSlots(expungeStaleEntry(slotToExpunge), len);
102 }
103 

       

 

       

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

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

 

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

  1 // ThreadLocalMap
  2 private Entry getEntry(ThreadLocal<?> key) {
  3             int i = key.threadLocalHashCode & (table.length - 1);
  4             Entry e = table[i];
  5             if (e != null && e.get() == key)
  6                 return e;
  7             else
  8                 return getEntryAfterMiss(key, i, e);
  9 }

  1        private Entry getEntry(ThreadLocal<?> key) {
  2             int i = key.threadLocalHashCode & (table.length - 1);
  3             Entry e = table[i];
  4             if (e != null && e.get() == key)
  5                 return e;
  6             else
  7             	//获取的时候出现失效的entry
  8                 return getEntryAfterMiss(key, i, e);
  9         }
 10 
 11 
 12         // 往后找，失效的值擦洗掉，没有就返回 Null
 13         private Entry getEntryAfterMiss(ThreadLocal<?> key, int i, Entry e) {
 14             Entry[] tab = table;
 15             int len = tab.length;
 16 
 17             while (e != null) {
 18                 ThreadLocal<?> k = e.get();
 19                 if (k == key)
 20                     return e;
 21                 if (k == null)
 22                     expungeStaleEntry(i);
 23                 else
 24                     i = nextIndex(i, len);
 25                 e = tab[i];
 26             }
 27             return null;
 28         }

 

使用ThreadLocal内存失效问题分析

为什么使用弱引用

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

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

• 没有任何引用指向它

• GC被运行.

         

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

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

  1 DemoA a=new DemoA();
  2 DemoB b=new DemoB(a);
  3 a=null;

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

  1 //方法1
  2 DemoA a=new DemoA();
  3 DemoB b=new DemoB(a);
  4 a=null;
  5 b=null;
  6 //方法2
  7 DemoA a=new DemoA();
  8 WeakReference b=new WeakReference(a);
  9 a=null;
 10 

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

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

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

 

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

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

  1 static class Entry extends WeakReference<ThreadLocal<?>> {
  2             /** The value associated with this ThreadLocal. */
  3             Object value;
  4 
  5             Entry(ThreadLocal<?> k, Object v) {
  6                 super(k);
  7                 value = v;
  8             }
  9         }

         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 方法，实现对对象的回收。

  1         private void remove(ThreadLocal<?> key) {
  2             Entry[] tab = table;
  3             int len = tab.length;
  4             int i = key.threadLocalHashCode & (len-1);
  5             for (Entry e = tab[i];
  6                  e != null;
  7                  e = tab[i = nextIndex(i, len)]) {
  8                 if (e.get() == key) {
  9                     e.clear();
 10                     expungeStaleEntry(i);
 11                     return;
 12                 }
 13             }
 14         }

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

 

其实我们从源码分析可以看到，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对象是如何区分的呢？ 

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

  1 static class ThreadLocalMap {
  2      static class Entry extends WeakReference<ThreadLocal<?>> {
  3 
  4        /** The value associated with this ThreadLocal. */
  5         Object value;
  6 
  7         Entry(ThreadLocal<?> k, Object v) {
  8                 super(k);
  9                value = v;
 10         }
 11      }
 12 
 13      ThreadLocalMap(ThreadLocal<?> firstKey, Object firstValue) {
 14 	   //构造一个Entry数组，并设置初始大小
 15            table = new Entry[INITIAL_CAPACITY];
 16            //计算Entry数据下标
 17            int i = firstKey.threadLocalHashCode & (INITIAL_CAPACITY - 1);
 18 	   //将`firstValue`存入到指定的table下标中
 19            table[i] = new Entry(firstKey, firstValue);
 20            size = 1;//设置节点长度为1
 21            setThreshold(INITIAL_CAPACITY); //设置扩容的阈值
 22       }
 23 //...省略部分代码
 24 }
 25 
 26 

  1 private final int threadLocalHashCode = nextHashCode();
  2 private static AtomicInteger nextHashCode = new AtomicInteger();
  3 private static final int HASH_INCREMENT = 0x61c88647;
  4 
  5 private static int nextHashCode() {
  6     return nextHashCode.getAndAdd(HASH_INCREMENT);
  7 }

        那为什么要使用到 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 的实现看散列算法