ThreadLocal原理解析

• hash冲突问题

  首先看一下ThreadLocal的这一段源码：

  public class ThreadLocal<T> {
      // 创建ThreadLocal对象时立马初始化threadLocalHashCode
      private final int threadLocalHashCode = nextHashCode();
        // 所有ThreadLocal对象共享
      private static AtomicInteger nextHashCode =
          new AtomicInteger();
  
      // 魔数，自增步长
      private static final int HASH_INCREMENT = 0x61c88647;
        // 每次自增固定的值
      private static int nextHashCode() {
          return nextHashCode.getAndAdd(HASH_INCREMENT);
      }
  }
  

  根据上面代码的解析，可以看出，每次new一个ThreadLocal对象，threadLocalHashCode的值都会在上一个对象的threadLocalHashCode值基础上自增一个固定长度“0x61c88647”。

  public void set(T value) {
                // 获取当前线程
          Thread t = Thread.currentThread();
                // 获取线程中的ThreadLocalMap容器对象
          ThreadLocalMap map = getMap(t);
                // 如果线程中已经有这个ThreadLocalMap容器对象了，那么直接把数据存进去
          if (map != null) {
                // 注意，这里的this指的就是当前的ThreadLocal对象本身
              map.set(this, value);
          } else {
                // 如果当前线程中还没有这个ThreadLocalMap容器对象，那么就现在创建一个
              createMap(t, value);
          }
      }
  
  // 说明ThreadLocalMap是线程中的一个对象
  ThreadLocalMap getMap(Thread t) {
          return t.threadLocals;
      }
  
  // 创建一个ThreadLocalMap容器对象，并且赋值给指定线程
  void createMap(Thread t, T firstValue) {
          t.threadLocals = new ThreadLocalMap(this, firstValue);
      }
  
  // 创建ThreadLocalMap容器对象
  ThreadLocalMap(ThreadLocal<?> firstKey, Object firstValue) {
                        // 初始化table数组
              table = new Entry[INITIAL_CAPACITY];
                        // 通过threadLocalHashCode计算目标索引值
              int i = firstKey.threadLocalHashCode & (INITIAL_CAPACITY - 1);
                        // 把ThreadLocal对象作为key，需要存储在线程中的数据作为value
              table[i] = new Entry(firstKey, firstValue);
              size = 1;
              setThreshold(INITIAL_CAPACITY);
          }
  

  通过上述代码，可以看出：

  • 每一个线程中都会有一个ThreadLocalMap容器，这个容器就是一个【key:value】数组。

  • ThreadLocal是把自己本身作为key，存储对象作为value。

  • 每一个ThreadLocal对象都有不同的threadLocalHashCode，以便于它们更好地离散分布在ThreadLocalMap中。

  • 一个ThreadLocal对象在一个线程中，只能存储一个对象 image-20210612124541065.png
    

    如果ThreadLocal达到一定数量，通过threadLocalHashCode & (INITIAL_CAPACITY - 1)的算法计算目标索引值，必定会存在两个不同的ThreadLocal命中同一个索引值的情况。

  private void set(ThreadLocal<?> key, Object value) {
              Entry[] tab = table;
              int len = tab.length;
                        // 计算索引值
              int i = key.threadLocalHashCode & (len-1);
                        // 在这个for循环中，只判断了
                        // 1.索引值下的key是否和当前ThreadLocal相等
                        // 2.索引值下的key是否为null
                        // 那么剩下的情况就是产生了hash冲突的情况
              for (Entry e = tab[i];
                   e != null;
                   // 3.如果产生hash冲突了，那么需要计算下一个目标索引位置下的Entry
                   e = tab[i = nextIndex(i, len)]) {
                    // 获取目标索引值下的key
                  ThreadLocal<?> k = e.get();
                                // 1.如果和当前的ThreadLocal是一个对象，那么直接取值
                  if (k == key) {
                      e.value = value;
                      return;
                  }
                    // 2.如果这个索引值下的key已经被回收掉了，那么肯定是直接覆盖掉这个位置
                  if (k == null) {
                        // replaceStaleEntry里面做了一些清理工作
                      replaceStaleEntry(key, value, i);
                      return;
                  }
              }
  
              tab[i] = new Entry(key, value);
              int sz = ++size;
              if (!cleanSomeSlots(i, sz) && sz >= threshold)
                  rehash();
          }
  // 写一个索引值就是一直向后自增，超过了整个容器大小，又回到索引0位置。
  // 注意：容器是有扩容策略的，如果ThreadLocal数量不是特别多的话，一般是不会到0索引位的。
   private static int nextIndex(int i, int len) {
              return ((i + 1 < len) ? i + 1 : 0);
          }
  
  // 检查是否需扩容
  private void rehash() {
    expungeStaleEntries();
    // 检查是否大于等于四分之三
    if (size >= threshold - threshold / 4)
      // 扩容
      resize();
  }
  
  // 扩容就是创建一个原来长度两倍的数组
  private void resize() {
    Entry[] oldTab = table;
    int oldLen = oldTab.length;
    int newLen = oldLen * 2;
    Entry[] newTab = new Entry[newLen];
    int count = 0;
    for (Entry e : oldTab) {
      if (e != null) {
        ThreadLocal<?> k = e.get();
        if (k == null) {
          e.value = null; // Help the GC
        } else {
          int h = k.threadLocalHashCode & (newLen - 1);
          while (newTab[h] != null)
            h = nextIndex(h, newLen);
          newTab[h] = e;
          count++;
        }
      }
    }
    setThreshold(newLen);
    size = count;
    table = newTab;
  }
  

  所以在ThreadLocalMap中，一旦出现hash冲突的情况，就会通过线性探测的方式寻找下一个可以存放数据的位置。

  get()方法也是一样，如果发现目标位置的key与当前的ThreadLocal不是一个对象，那么也会通过线性探测的方式寻找目标位置，直至满足条件。

• 内存泄漏问题

  首先，如果我们的线程不会循环使用的话，本身是不存在内存泄漏的问题的。因为线程属性threadLocals会随着线程的消亡被回收，也就不可能内存泄漏。

  因为线程资源宝贵，为了减少线程的创建，对线程做了循环利用。那么就会导致线程中的threadLocals在下一次使用前还有[key:value]键值对，并且因为一直有一个强引用指定value，那么gc并不会导致value的回收，在不断的循环利用过程中，必然会导致更多的value被创建而不被gc回收，最终导致内存泄漏。

  1.如果Entry中的key使用强引用的话，那么需要使用者手动将ThreadLocal置为null，否则ThreadLocal对象始终会有一个强引用被ThreadLocalMap持有，那么永远不会被回收，导致内存泄漏。

  2.如果Entry中的key使用弱引用的话，当ThreadLocal没有被任何对象任何强引用的时候，也就是该被回收的时候，那么就直接被回收了，不会因为ThreadLocalMap持有它的弱引用，导致它一直无法被回收而造成内存泄漏。

  其实从设计层面来说的话，也体现了ThreadLocal的封装性，既然不让开发者关心具体的key如何操作，那么自身内部就应该保证使用ThreadLocal的内存安全性，而不应该让使用者来处理和关心ThreadLocalMap对ThreadLocal的引用问题。

为了证明一下只要ThreadLocal没有任何其他强引用，那么经过gc后就会立马被回收，我写了下面这段代码：

public static void main(String[] args) throws InterruptedException {
        CountDownLatch countDownLatch = new CountDownLatch(1);
        new Thread(
                        () -> {
                            // 创建一个ThreadLocal对象
                            ThreadLocal<String> threadLocal = new ThreadLocal<>();
                            threadLocal.set("hello world");
                            // 让ThreadLocal对象没有任何强引用
                            threadLocal = null;
                            System.gc();
                            // 获取当前线程
                            Thread currentThread = Thread.currentThread();
                            // 可以在这一行打断点，查看currentThread里面的threadLocals对象
                            countDownLatch.countDown();
                        })
                .start();
        countDownLatch.await();
    }

image-20210612140215761.png

如上图所示，gc后referent属性值为null，说明此时Entry中的key已经被回收了，但是value依然存在。

如何处理value的强引用？

可参照以下模版：

ThreadLocal<String> threadLocal = new ThreadLocal<>();
try{
  threadLocal.set("hello world");
    // todo
}finally{
  threadLocal.remove();
}

无论key是强引用还是弱引用，threadLocal都必须要在代码逻辑执行完毕后调用remove()将value的强引用删掉，否则就会导致内存泄漏。
也就是说，ThreadLocal不需要开发者关心key的回收问题，开发者只需要关心自己操作的value的回收问题即可。内部的归内部管理，外部的归外部管理，各司其职。