ThreadLocal从入门到精通（底层实现、算法、内存泄露分析）

╰半橙微兮° 2023-10-01 21:13 6阅读 0赞

#### 文章目录 ####

*  前言
 *  一、ThreadLocal是什么，它和synchronized有什么区别？
 *  二、ThreadLocal的底层数据结构包含哪些内容？
 *  三、ThreadLocal的核心方法源码
 *   *  （一）set方法
     *  （二）get方法
     *  （三）remove方法
 *  四、ThreadLocalMap源码分析
 *   *  （一） 成员变量
     *  （二）存储结构 - Entry
 *  五、ThreadLocalMap的key是强引用，还是弱引用？为什么？
 *  六、ThreadLocalMap的初始大小、加载因子分别是多少？
 *  七、ThreadLocal底层用到的Hash算法是什么？
 *  八、ThreadLocal如何解决Hash冲突？
 *  九、ThreadLocal底层的扩容机制是什么？
 *  十、ThreadLocal使用场景

--------------------

## 前言 ##

ThreadLocal是多线程编程的一个重要知识点，而且市场应用点非常多，例如Web系统Session的存储就是ThreadLocal一个典型的应用场景。本文带你从入门到精通ThreadLocal！

--------------------

## 一、ThreadLocal是什么，它和synchronized有什么区别？ ##

`ThreadLocal`类用来提供线程内部的局部变量。这种变量在多线程环境下访问（通过get和set方法访问）时能保证各个线程的变量相对独立于其他线程内的变量。ThreadLocal实例通常来说都是private static类型的，用于关联线程和线程上下文。

它一共有四个常用的方法

<table> 
 <thead> 
  <tr> 
   <th>方法声明</th> 
   <th>描述</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>ThreadLocal()</td> 
   <td>创建ThreadLocal对象</td> 
  </tr> 
  <tr> 
   <td>public void set( T value)</td> 
   <td>设置当前线程绑定的局部变量</td> 
  </tr> 
  <tr> 
   <td>public T get()</td> 
   <td>获取当前线程绑定的局部变量</td> 
  </tr> 
  <tr> 
   <td>public void remove()</td> 
   <td>移除当前线程绑定的局部变量</td> 
  </tr> 
 </tbody> 
</table>

有人就会问到了，在多线程环境下，想要保证线程同步访问一段资源，用synchronized不也可以做到吗，为什么要用ThreadLocal？或者说使用ThreadLocal有什么好处？

接下来我们来看一个案例：

public class MyDemo {
        
        private String content;
    
        private String getContent() {
        
            return content;
        }
    
        private void setContent(String content) {
        
            this.content = content;
        }
    
        public static void main(String[] args) {
        
            MyDemo demo = new MyDemo();
            for (int i = 0; i < 5; i++) {
        
                Thread thread = new Thread(new Runnable() {
        
                    @Override
                    public void run() {
        
                        demo.setContent(Thread.currentThread().getName() + "的数据");
                        System.out.println("-----------------------");
                        System.out.println(Thread.currentThread().getName() + "--->" + demo.getContent());
                    }
                });
                thread.setName("线程" + i);
                thread.start();
            }
        }
    }

程序很简单，开启5个线程，每个线程都会在run方法中进行set当前线程的资源和get资源  
运行结果如下：

> 线程1—>线程1的数据  
> 线程0—>线程1的数据  
> 线程2—>线程4的数据  
> 线程4—>线程4的数据  
> 线程3—>线程3的数据

我们会发现线程0和线程2访问到了不属于自己的资源，这就会存在并发问题，好的，接下里我们尝试着用synchronized加锁

public class Demo02 {
        
        
        private String content;
    
        public String getContent() {
        
            return content;
        }
    
        public void setContent(String content) {
        
            this.content = content;
        }
    
        public static void main(String[] args) {
        
            Demo02 demo02 = new Demo02();
            
            for (int i = 0; i < 5; i++) {
        
                Thread t = new Thread(){
        
                    @Override
                    public void run() {
        
                        synchronized (Demo02.class){
        
                            demo02.setContent(Thread.currentThread().getName() + "的数据");
                            System.out.println("-------------------------------------");
                            String content = demo02.getContent();
                            System.out.println(Thread.currentThread().getName() + "--->" + content);
                        }
                    }
                };
                t.setName("线程" + i);
                t.start();
            }
        }
    }

运行结果：

> 线程0—>线程0的数据  
> 线程3—>线程3的数据  
> 线程4—>线程4的数据  
> 线程2—>线程2的数据  
> 线程1—>线程1的数据

运行结果证明：用synchronized可以解决线程同步安全性问题

接下来用ThreadLocal试试

public class MyDemo1 {
        
    
        private static ThreadLocal<String> tl = new ThreadLocal<>();
    
        private String content;
    
        private String getContent() {
        
            return tl.get();
        }
    
        private void setContent(String content) {
        
             tl.set(content);
        }
    
        public static void main(String[] args) {
        
            MyDemo1 demo = new MyDemo1();
            for (int i = 0; i < 5; i++) {
        
                Thread thread = new Thread(new Runnable() {
        
                    @Override
                    public void run() {
        
                        demo.setContent(Thread.currentThread().getName() + "的数据");
                        System.out.println("-----------------------");
                        System.out.println(Thread.currentThread().getName() + "--->" + demo.getContent());
                    }
                });
                thread.setName("线程" + i);
                thread.start();
            }
        }
    }

运行结果：

> 线程3—>线程3的数据  
> 线程2—>线程2的数据  
> 线程0—>线程0的数据  
> 线程1—>线程1的数据  
> 线程4—>线程4的数据

**同样没问题，但是关键之处在于，我们这里强调的是`线程隔离`，而不是`线程同步`的问题，在这种案例中用synchronized显然是不合适的。**

**ThreadLocal与synchronized的区别**

<table> 
 <thead> 
  <tr> 
   <th></th> 
   <th>synchronized</th> 
   <th>ThreadLocal</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>原理</td> 
   <td>同步机制采用’以时间换空间’的方式, 只提供了一份变量,让不同的线程排队访问</td> 
   <td>ThreadLocal采用’以空间换时间’的方式, 为每一个线程都提供了一份变量的副本,从而实现同时访问而相不干扰</td> 
  </tr> 
  <tr> 
   <td>侧重点</td> 
   <td>多个线程之间访问资源的同步</td> 
   <td>多线程中让每个线程之间的数据相互隔离</td> 
  </tr> 
 </tbody> 
</table>

## 二、ThreadLocal的底层数据结构包含哪些内容？ ##

ThreadLocal内部结构，可以透露的是它的底层采用了ThreadLocalMap这一种Map的存储结构。说到这里，就会有人觉得，在这个Map结构中，key是不是当前线程，而value则存放着局部变量资源呢？JDK早期确实是这样设计的，但是现在不是。

**早期设计**  
![在这里插入图片描述][300d96c1e64649e0b378a98eebb89362.png_type_d3F5LXplbmhlaQ_shadow_50_text_Q1NETiBA6IuPYnJv_size_20_color_FFFFFF_t_70_g_se_x_16]  
**如今设计**  
![在这里插入图片描述][9db11c4555d747a4b633a6af88cba54a.png_type_d3F5LXplbmhlaQ_shadow_50_text_Q1NETiBA6IuPYnJv_size_20_color_FFFFFF_t_70_g_se_x_16]  
我们通过图示可以看出，现在的`ThreadLocal`的设计是：每个`Thread`维护一个`ThreadLocalMap`，这个Map的key是ThreadLocal实例本身，value才是真正要存储的值Object。

**具体的过程是这样的：**

*  每个Thread线程内部都有一个Map (ThreadLocalMap)
 *  Map里面存储ThreadLocal对象（key）和线程的变量副本（value）
 *  Thread内部的Map是由ThreadLocal维护的，由ThreadLocal负责向map获取和设置线程的变量值。
 *  对于不同的线程，每次获取副本值时，别的线程并不能获取到当前线程的副本值，形成了副本的隔离，互不干扰。

**这样设计的好处如下：**

*  这样设计之后每个Map存储的Entry数量就会变少。因为之前的存储数量由Thread的数量决定，现在是由ThreadLocal的数量决定。在实际运用当中，往往ThreadLocal的数量要少于Thread的数量。
 *  当Thread销毁之后，对应的ThreadLocalMap也会随之销毁，能减少内存的使用。

## 三、ThreadLocal的核心方法源码 ##

### （一）set方法 ###

/**
         * 设置当前线程对应的ThreadLocal的值
         *
         * @param value 将要保存在当前线程对应的ThreadLocal的值
         */
        public void set(T value) {
        
            // 获取当前线程对象
            Thread t = Thread.currentThread();
            // 获取此线程对象中维护的ThreadLocalMap对象
            ThreadLocalMap map = getMap(t);
            // 判断map是否存在
            if (map != null)
                // 存在则调用map.set设置此实体entry
                map.set(this, value);
            else
                // 1）当前线程Thread 不存在ThreadLocalMap对象
                // 2）则调用createMap进行ThreadLocalMap对象的初始化
                // 3）并将 t(当前线程)和value(t对应的值)作为第一个entry存放至ThreadLocalMap中
                createMap(t, value);
        }
    
     /**
         * 获取当前线程Thread对应维护的ThreadLocalMap 
         * 
         * @param  t the current thread 当前线程
         * @return the map 对应维护的ThreadLocalMap 
         */
        ThreadLocalMap getMap(Thread t) {
        
            return t.threadLocals;
        }
    	/**
         *创建当前线程Thread对应维护的ThreadLocalMap 
         *
         * @param t 当前线程
         * @param firstValue 存放到map中第一个entry的值
         */
    	void createMap(Thread t, T firstValue) {
        
            //这里的this是调用此方法的threadLocal
            t.threadLocals = new ThreadLocalMap(this, firstValue);
        }

**总结就是：set方法，先通过getMap()方法得到当前线程维护的ThreadLocalMap对象，该map对象存在时就将ThreadLocal对象作为key，加上value值在Map中设置成为一个entry；若该map对象不存在时，则调用createMap进行ThreadLocalMap对象的初始化，并将 t(当前线程)和value(t对应的值)作为第一个entry存放至ThreadLocalMap中。**

### （二）get方法 ###

/**
         * 返回当前线程中保存ThreadLocal的值
         * 如果当前线程没有此ThreadLocal变量，
         * 则它会通过调用{@link #initialValue} 方法进行初始化值
         *
         * @return 返回当前线程对应此ThreadLocal的值
         */
        public T get() {
        
            // 获取当前线程对象
            Thread t = Thread.currentThread();
            // 获取此线程对象中维护的ThreadLocalMap对象
            ThreadLocalMap map = getMap(t);
            // 如果此map存在
            if (map != null) {
        
                // 以当前的ThreadLocal 为 key，调用getEntry获取对应的存储实体e
                ThreadLocalMap.Entry e = map.getEntry(this);
                // 对e进行判空 
                if (e != null) {
        
                    @SuppressWarnings("unchecked")
                    // 获取存储实体 e 对应的 value值
                    // 即为我们想要的当前线程对应此ThreadLocal的值
                    T result = (T)e.value;
                    return result;
                }
            }
            /*
            	初始化 : 有两种情况有执行当前代码
            	第一种情况: map不存在，表示此线程没有维护的ThreadLocalMap对象
            	第二种情况: map存在, 但是没有与当前ThreadLocal关联的entry
             */
            return setInitialValue();
        }
    
        /**
         * 初始化
         *
         * @return the initial value 初始化后的值
         */
        private T setInitialValue() {
        
            // 调用initialValue获取初始化的值
            // 此方法可以被子类重写, 如果不重写默认返回null
            T value = initialValue();
            // 获取当前线程对象
            Thread t = Thread.currentThread();
            // 获取此线程对象中维护的ThreadLocalMap对象
            ThreadLocalMap map = getMap(t);
            // 判断map是否存在
            if (map != null)
                // 存在则调用map.set设置此实体entry
                map.set(this, value);
            else
                // 1）当前线程Thread 不存在ThreadLocalMap对象
                // 2）则调用createMap进行ThreadLocalMap对象的初始化
                // 3）并将 t(当前线程)和value(t对应的值)作为第一个entry存放至ThreadLocalMap中
                createMap(t, value);
            // 返回设置的值value
            return value;
        }
    
        protected T initialValue() {
        
            return null;
        }

**总结就是：get方法同样先获取此线程对象中维护的ThreadLocalMap对象，map存在时就以当前ThreadLocal对象作为key通过调用map.getEntry得到对应的entry。entry不为空就直接拿到set的时候存储的value值。如果entry为空，则说明当前线程 1）map不存在，表示此线程没有维护的ThreadLocalMap对象 2）map存在, 但是没有与当前ThreadLocal关联的entry。接下来就要通过调用setInitialValue()方法进行初始化操作**

**setInitialValue()方法用于建立初始值，如果用户重写了set()方法，则使用它代替set。看源码也会发现它还是先获取当前线程维护的ThreadLocalMap对象，存在则设置key为ThreadLocal对象，value为null的entry实体；不存在则调用createMap进行ThreadLocalMap对象的初始化，也是将key为ThreadLocal对象，value为null作为第一个entry放进ThreadLocalMap中**

### （三）remove方法 ###

/**
         * 删除当前线程中保存的ThreadLocal对应的实体entry
         */
         public void remove() {
        
            // 获取当前线程对象中维护的ThreadLocalMap对象
             ThreadLocalMap m = getMap(Thread.currentThread());
            // 如果此map存在
             if (m != null)
                // 存在则调用map.remove
                // 以当前ThreadLocal为key删除对应的实体entry
                 m.remove(this);
         }

**remove()方法比较简单，直接将当前线程维护的ThreadLocalMap中把以当前ThreadLocal为key删除对应的实体entry**

## 四、ThreadLocalMap源码分析 ##

再读ThreadLocalMap源码之前，建议有HashMap的基础，否则读起来比较困难，我的另一篇文章里面有详细介绍HashMap的底层源码分析，链接如下：  
[2022年，我用两万字详细总结HashMap(JDK1.8)底层原理][2022_HashMap_JDK1.8]

ThreadLocalMap并没有实现某个Map接口，而是用独立的方式实现了Map的功能，其内部的Entry也是独立实现。

![在这里插入图片描述][c5faa49103224331a66e1e01470f46fd.png_type_d3F5LXplbmhlaQ_shadow_50_text_Q1NETiBA6IuPYnJv_size_20_color_FFFFFF_t_70_g_se_x_16]

### （一） 成员变量 ###

/**
         * 初始容量 —— 必须是2的整次幂
         */
        private static final int INITIAL_CAPACITY = 16;
    
        /**
         * 存放数据的table，Entry类的定义在下面分析
         * 同样，数组长度必须是2的整次幂。
         */
        private Entry[] table;
    
        /**
         * 数组里面entrys的个数，可以用于判断table当前使用量是否超过阈值。
         */
        private int size = 0;
    
        /**
         * 进行扩容的阈值，表使用量大于它的时候进行扩容。
         */
        private int threshold; // Default to 0

跟HashMap类似，INITIAL\_CAPACITY代表这个Map的初始容量；table 是一个Entry 类型的数组，用于存储数据；size 代表表中的存储数目； threshold 代表需要扩容时对应 size 的阈值。

### （二）存储结构 - Entry ###

/*
     * Entry继承WeakReference，并且用ThreadLocal作为key.
     * 如果key为null(entry.get() == null)，意味着key不再被引用，
     * 因此这时候entry也可以从table中清除。
     */
    static class Entry extends WeakReference<ThreadLocal<?>> {
        
        /** The value associated with this ThreadLocal. */
        Object value;
    
        Entry(ThreadLocal<?> k, Object v) {
        
            super(k);
            value = v;
        }
    }

在ThreadLocalMap中，也是用Entry来保存K-V结构数据的。不过Entry中的key只能是ThreadLocal对象，这点在构造方法中已经限定死了。

另外，Entry继承WeakReference，也就是key（ThreadLocal）是弱引用，其目的是将ThreadLocal对象的生命周期和线程生命周期解绑。

## 五、ThreadLocalMap的key是强引用，还是弱引用？为什么？ ##

答案是：弱引用

在解释为什么用弱引用之前不得不提一个经典ThreadLocal面试问题：ThreadLocal为什么会存在内存泄露问题？  
我们最先会想到的是因为弱引用，但实际上并不是

我们先来回顾一下`弱引用`与`强引用`的概念：

> **强引用（“Strong” Reference）**，就是我们最常见的普通对象引用，只要还有强引用指向一个对象，就能表明对象还“活着”，垃圾回收器就不会回收这种对象。
> 
> **弱引用（WeakReference）**，垃圾回收器一旦发现了只具有弱引用的对象，不管当前内存空间足够与否，都会回收它的内存。

如果使用强引用会怎么样？  
结合ThreadLocal的内存图来分析（实线表示强引用，虚线表示弱引用）  
![在这里插入图片描述][a6df87d824994027afa13eedc1a43f50.png_type_d3F5LXplbmhlaQ_shadow_50_text_Q1NETiBA6IuPYnJv_size_20_color_FFFFFF_t_70_g_se_x_16]  
假设在业务代码中使用完ThreadLocal ，ThreadLocal Ref被回收了。

但是因为ThreadLocalMap的Entry强引用了ThreadLocal，造成ThreadLocal无法被回收。

在没有手动删除这个Entry以及CurrentThread依然运行的前提下，始终有强引用链 threadRef->currentThread->threadLocalMap->entry，Entry就不会被回收（Entry中包括了ThreadLocal实例和value），导致Entry内存泄漏。

也就是说，ThreadLocalMap中的key使用了强引用， 是无法完全避免内存泄漏的。

如果使用弱引用呢？  
结合ThreadLocal的内存图来分析（实线表示强引用，虚线表示弱引用）  
![在这里插入图片描述][4ed9efcb96544f8381483cf2c2b050a7.png_type_d3F5LXplbmhlaQ_shadow_50_text_Q1NETiBA6IuPYnJv_size_20_color_FFFFFF_t_70_g_se_x_16]  
同样假设在业务代码中使用完ThreadLocal ，ThreadLocal Ref被回收了。

由于ThreadLocalMap只持有ThreadLocal的弱引用，没有任何强引用指向Threadlocal实例, 所以Threadlocal就可以顺利被gc回收，此时Entry中的key=null。

但是在没有手动删除这个Entry以及CurrentThread依然运行的前提下，也存在有强引用链 ThreadRef->CurrentThread->ThreadLocalMap->entry -> value ，value不会被回收， 而这块value永远不会被访问到了，导致value内存泄漏。

**也就是说，ThreadLocalMap中的key使用了弱引用， 也有可能内存泄漏，那么内存泄露的问题就不是使用弱引用和强引用的关系了。**

出现内存泄露的真正原因是什么？  
细心的同学会发现，在以上两种内存泄漏的情况中，都有两个前提：

> 1、没有手动删除这个Entry  
> 2、CurrentThread依然运行

第一点很好理解，只要在使用完ThreadLocal，调用其remove方法删除对应的Entry，就能避免内存泄漏。

第二点稍微复杂一点， 由于ThreadLocalMap是Thread的一个属性，被当前线程所引用，所以它的生命周期跟Thread一样长。那么在使用完ThreadLocal之后，如果当前Thread也随之执行结束，ThreadLocalMap自然也会被gc回收，从根源上避免了内存泄漏。

**综上，ThreadLocal内存泄漏的根源是：由于ThreadLocalMap的生命周期跟Thread一样长，如果没有手动删除对应key就会导致内存泄漏。**

为什么使用弱引用？

根据刚才的分析, 我们知道了： 无论ThreadLocalMap中的key使用哪种类型引用都无法完全避免内存泄漏，跟使用弱引用没有关系。

要避免内存泄漏有两种方式：

1.  使用完ThreadLocal，调用其remove方法删除对应的Entry
2.  使用完ThreadLocal，当前Thread也随之运行结束

> 相对第一种方式，第二种方式显然更不好控制，特别是使用线程池的时候，线程结束是不会销毁的。

也就是说，只要记得在使用完ThreadLocal及时的调用remove，无论key是强引用还是弱引用都不会有问题。**那么为什么key要用弱引用呢？**

事实上，在ThreadLocalMap中的set/getEntry方法中，会对key为null（也即是ThreadLocal为null）进行判断，如果为null的话，那么是会对value置为null的。  
![在这里插入图片描述][watermark_type_d3F5LXplbmhlaQ_shadow_50_text_Q1NETiBA6IuPYnJv_size_20_color_FFFFFF_t_70_g_se_x_16]  
![在这里插入图片描述][watermark_type_d3F5LXplbmhlaQ_shadow_50_text_Q1NETiBA6IuPYnJv_size_20_color_FFFFFF_t_70_g_se_x_16 1]  
![在这里插入图片描述][watermark_type_d3F5LXplbmhlaQ_shadow_50_text_Q1NETiBA6IuPYnJv_size_20_color_FFFFFF_t_70_g_se_x_16 2]

这就意味着使用完ThreadLocal，CurrentThread依然运行的前提下，就算忘记调用remove方法，**弱引用比强引用可以多一层保障**：弱引用的ThreadLocal会被回收，对应的value在下一次ThreadLocalMap调用set,get,remove中的任一方法的时候会被清除，从而避免内存泄漏。

## 六、ThreadLocalMap的初始大小、加载因子分别是多少？ ##

来看看我们ThreadLocalMap的构造函数  
`ThreadLocalMap(ThreadLocal<?> firstKey, Object firstValue)`

ThreadLocalMap(ThreadLocal<?> firstKey, Object firstValue) {
        
        table = new Entry[INITIAL_CAPACITY];  //初始化大小为16
        int i = firstKey.threadLocalHashCode & (INITIAL_CAPACITY - 1);
        table[i] = new Entry(firstKey, firstValue);
        size = 1;
        setThreshold(INITIAL_CAPACITY);
    }
    //设置调整大小阈值以保持最坏的 2/3 负载因子
    private void setThreshold(int len) {
        
        threshold = len * 2 / 3;
    }
    
    INITIAL_CAPACITY:是ThreadLocalMap的初始化大小，为16

从构造函数我们可以得出结论，ThreadLocalMap的初始大小是16  
加载因子由setThreadshold设置阈值大小的时候可以看出，是2/3

## 七、ThreadLocal底层用到的Hash算法是什么？ ##

ThreadLocal底层的Hash算法就是ThreadLocalMap构造函数中的这一段代码  
`int i = firstKey.threadLocalHashCode & (INITIAL_CAPACITY - 1)`

（一）先来看`firstKey.threadLocalHashCode`

private final int threadLocalHashCode = nextHashCode();
    
    private static int nextHashCode() {
        
        return nextHashCode.getAndAdd(HASH_INCREMENT);
    }
    //AtomicInteger是一个提供原子操作的Integer类，通过线程安全的方式操作加减,适合高并发情况下的使用
    private static AtomicInteger nextHashCode =  new AtomicInteger();
     //特殊的hash值
    private static final int HASH_INCREMENT = 0x61c88647;

这里定义了一个AtomicInteger类型，每次获取当前值并加上HASH\_INCREMENT，HASH\_INCREMENT = 0x61c88647,这个值跟斐波那契数列（黄金分割数）有关，其主要目的就是为了让哈希码能均匀的分布在2的n次方的数组里, 也就是Entry\[\] table中，这样做可以尽量避免hash冲突。

（二）再看`& (INITIAL_CAPACITY - 1)`  
计算hash的时候里面采用了hashCode & (size - 1)的算法，这相当于取模运算hashCode % size的一个更高效的实现。正是因为这种算法，我们要求size必须是2的整次幂，这也能保证在索引不越界的前提下，使得hash发生冲突的次数减小。

## 八、ThreadLocal如何解决Hash冲突？ ##

Hash冲突我们知道，是在存放entry的时候，通过hash计算得到的数组索引值，在投放到数组中的时候发现已经有元素存在了，那么就会产生hash冲突。

ThreadLocal解决Hash冲突的办法是`线性探测法`

我们接下来通过ThreadLocalMap中的set方法展示一下线性探测法是怎么运作的  
**ThreadLocalMap中的set方法**

private void set(ThreadLocal<?> key, Object value) {
        
            ThreadLocal.ThreadLocalMap.Entry[] tab = table;
            int len = tab.length;
            //计算索引(重点代码，刚才分析过了）
            int i = key.threadLocalHashCode & (len-1);
            /**
             * 使用线性探测法查找元素（重点代码）
             */
            for (ThreadLocal.ThreadLocalMap.Entry e = tab[i];
                 e != null;
                 e = tab[i = nextIndex(i, len)]) {
        
                ThreadLocal<?> k = e.get();
                //ThreadLocal 对应的 key 存在，直接覆盖之前的值
                if (k == key) {
        
                    e.value = value;
                    return;
                }
                // key为 null，但是值不为 null，说明之前的 ThreadLocal 对象已经被回收了，
               // 当前数组中的 Entry 是一个陈旧（stale）的元素
                if (k == null) {
        
                    //用新元素替换陈旧的元素，这个方法进行了不少的垃圾清理动作，防止内存泄漏
                    replaceStaleEntry(key, value, i);
                    return;
                }
            }
        
        	//ThreadLocal对应的key不存在并且没有找到陈旧的元素，则在空元素的位置创建一个新的Entry。
                tab[i] = new Entry(key, value);
                int sz = ++size;
                /**
                 * cleanSomeSlots用于清除那些e.get()==null的元素，
                 * 这种数据key关联的对象已经被回收，所以这个Entry(table[index])可以被置null。
                 * 如果没有清除任何entry,并且当前使用量达到了负载因子所定义(长度的2/3)，那么进行				 * rehash（执行一次全表的扫描清理工作）
                 */
                if (!cleanSomeSlots(i, sz) && sz >= threshold)
                    rehash();
    }
    
     /**
         * 获取环形数组的下一个索引
         */
        private static int nextIndex(int i, int len) {
        
            return ((i + 1 < len) ? i + 1 : 0);
        }

代码执行流程：

A. 首先还是根据key计算出索引 i，然后查找i位置上的Entry，

B. 若是Entry已经存在并且key等于传入的key，那么这时候直接给这个Entry赋新的value值,

C. 若是Entry存在，但是key为null，则调用replaceStaleEntry来更换这个key为空的Entry,

D. 不断循环检测，直到遇到为null的地方，这时候要是还没在循环过程中return，那么就在这个null的位置新建一个Entry，并且插入，同时size增加1。

E. 最后调用cleanSomeSlots，清理key为null的Entry，最后返回是否清理了Entry，接下来再判断sz 是否>= thresgold达到了rehash的条件，达到的话就会调用rehash函数执行一次全表的扫描清理

**重点分析** ： **ThreadLocalMap使用线性探测法来解决哈希冲突的。**

该方法一次探测下一个地址，直到有空的地址后插入，若整个空间都找不到空余的地址，则产生溢出。

举个例子，假设当前table长度为16，也就是说如果计算出来key的hash值为14，如果table\[14\]上已经有值，并且其key与当前key不一致，那么就发生了hash冲突，这个时候将14加1得到15，取table\[15\]进行判断，这个时候如果还是冲突会回到0，取table\[0\],以此类推，直到可以插入。

按照上面的描述，可以把Entry\[\] table看成一个环形数组。

## 九、ThreadLocal底层的扩容机制是什么？ ##

在上面的set方法中，在最后会判断当前下标往后的元素是否存在需要value回收的，如果不存在需要回收并且当前总元素大于等于阈值，那么就会调用rehash()扩容。

rehash()源码

/**
     *重新包装和/或重新调整桌子的大小。首先扫描整个表删除过时的条目。
     *如果这不能充分缩小表格的大小，请将表格大小加倍
     */
    private void rehash() {
        
        expungeStaleEntries(); //清除表中所有过时的条目
    
        // Use lower threshold for doubling to avoid hysteresis
        if (size >= threshold - threshold / 4)
            resize();  //扩容
    }

扩容之前还会再重新对key已经被GC了的元素进行回收，回收后如果总数还是大于等于阈值的3/4，那么就会调用resize()进行真正的扩容。

核心扩容resize()

private void resize() {
        
        Entry[] oldTab = table;
        int oldLen = oldTab.length;
        int newLen = oldLen * 2;  //扩容到原来的2倍
        Entry[] newTab = new Entry[newLen];
        int count = 0;
    
        for (int j = 0; j < oldLen; ++j) {
        
            Entry e = oldTab[j];
            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;
    }

可以看到newLen的长度是原来长度的2倍，也就代表着扩容到原来的2倍大小，并且所有的元素还会重新计算一次hash操作，阈值也会更新。

## 十、ThreadLocal使用场景 ##

Web系统Session的存储就是ThreadLocal一个典型的应用场景。

Web容器采用线程隔离的多线程模型，也就是每一个请求都会对应一条线程，线程之间相互隔离，没有共享数据。这样能够简化编程模型，程序员可以用单线程的思维开发这种多线程应用。

当请求到来时，可以将当前Session信息存储在ThreadLocal中，在请求处理过程中可以随时使用Session信息，每个请求之间的Session信息互不影响。当请求处理完成后通过remove方法将当前Session信息清除即可。

--------------------

参考链接：  
https://blog.csdn.net/weixin\_44050144/article/details/113061884  
https://zhuanlan.zhihu.com/p/402281916  
https://zhuanlan.zhihu.com/p/34494674

[300d96c1e64649e0b378a98eebb89362.png_type_d3F5LXplbmhlaQ_shadow_50_text_Q1NETiBA6IuPYnJv_size_20_color_FFFFFF_t_70_g_se_x_16]: https://img-blog.csdnimg.cn/300d96c1e64649e0b378a98eebb89362.png?type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA6IuPYnJv,size_20,color_FFFFFF,t_70,g_se,x_16
[9db11c4555d747a4b633a6af88cba54a.png_type_d3F5LXplbmhlaQ_shadow_50_text_Q1NETiBA6IuPYnJv_size_20_color_FFFFFF_t_70_g_se_x_16]: https://img-blog.csdnimg.cn/9db11c4555d747a4b633a6af88cba54a.png?type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA6IuPYnJv,size_20,color_FFFFFF,t_70,g_se,x_16
[2022_HashMap_JDK1.8]: https://blog.csdn.net/weixin_51201930/article/details/122716035
[c5faa49103224331a66e1e01470f46fd.png_type_d3F5LXplbmhlaQ_shadow_50_text_Q1NETiBA6IuPYnJv_size_20_color_FFFFFF_t_70_g_se_x_16]: https://img-blog.csdnimg.cn/c5faa49103224331a66e1e01470f46fd.png?type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA6IuPYnJv,size_20,color_FFFFFF,t_70,g_se,x_16
[a6df87d824994027afa13eedc1a43f50.png_type_d3F5LXplbmhlaQ_shadow_50_text_Q1NETiBA6IuPYnJv_size_20_color_FFFFFF_t_70_g_se_x_16]: https://img-blog.csdnimg.cn/a6df87d824994027afa13eedc1a43f50.png?type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA6IuPYnJv,size_20,color_FFFFFF,t_70,g_se,x_16
[4ed9efcb96544f8381483cf2c2b050a7.png_type_d3F5LXplbmhlaQ_shadow_50_text_Q1NETiBA6IuPYnJv_size_20_color_FFFFFF_t_70_g_se_x_16]: https://img-blog.csdnimg.cn/4ed9efcb96544f8381483cf2c2b050a7.png?type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA6IuPYnJv,size_20,color_FFFFFF,t_70,g_se,x_16
[watermark_type_d3F5LXplbmhlaQ_shadow_50_text_Q1NETiBA6IuPYnJv_size_20_color_FFFFFF_t_70_g_se_x_16]: https://img-blog.csdnimg.cn/824e5db4f045402caf3ebc195ad9867e.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA6IuPYnJv,size_20,color_FFFFFF,t_70,g_se,x_16
[watermark_type_d3F5LXplbmhlaQ_shadow_50_text_Q1NETiBA6IuPYnJv_size_20_color_FFFFFF_t_70_g_se_x_16 1]: https://img-blog.csdnimg.cn/f31fc537527545beb83a0e74c68f666f.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA6IuPYnJv,size_20,color_FFFFFF,t_70,g_se,x_16
[watermark_type_d3F5LXplbmhlaQ_shadow_50_text_Q1NETiBA6IuPYnJv_size_20_color_FFFFFF_t_70_g_se_x_16 2]: https://img-blog.csdnimg.cn/4a8df392328342d8950b67e05bf631d0.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA6IuPYnJv,size_20,color_FFFFFF,t_70,g_se,x_16