谈一谈对ThreadLocal的理解

迷南。 2023-03-03 05:55 14阅读 0赞

## 什么是ThreadLocal？ ##

ThreadLocal提供一个线程的局部变量，访问某个线程拥有自己局部变量。当使用ThreadLocal维护变量时，ThreadLocal为每个使用该变量的线程提供独立的变量副本，所以每一个线程都可以独立地改变自己的副本，而不会影响其它线程所对应的副本。

## ThreadLocal的作用 ##

ThreadLocal的作用主要是做数据隔离，填充的数据只属于当前线程，变量的数据对别的线程而言是相对隔离的，在多线程环境下，可以防止自己的变量被其它线程篡改。

## ThreadLocal的使用场景 ##

经典的使用场景是为每个线程分配一个 JDBC 连接 Connection。这样就可以保证每个线程的都在各自的 Connection 上进行数据库的操作，不会出现 A 线程关了 B线程正在使用的 Connection； 还有 Session 管理 等问题。

项目中存在一个线程经常遇到横跨若干方法调用，需要传递的对象，也就是上下文（Context），它是一种状态，经常就是是用户身份、任务信息等，就会存在过渡传参的问题。  
使用到类似责任链模式，给每个方法增加一个context参数非常麻烦，而且有些时候，如果调用链有无法修改源码的第三方库，对象参数就传不进去了，所以我使用到了ThreadLocal去做了一下改造，这样只需要在调用前在ThreadLocal中设置参数，其他地方get一下就好了。

before
      
    void work(User user) { 
        getInfo(user);
        checkInfo(user);
        setSomeThing(user);
        log(user);
    }
    
    then
      
    void work(User user) { 
    try{ 
    	  threadLocalUser.set(user);
    	  // 他们内部 User u = threadLocalUser.get(); 就好了
        getInfo();
        checkInfo();
        setSomeThing();
        log();
        } finally { 
         threadLocalUser.remove();
        }
    }

## ThreadLocal的接口方法 ##

ThreadLocal类接口很简单，只有4个方法，我们先来了解一下：

*  void set(Object value)设置当前线程的线程局部变量的值。
 *  public Object get()该方法返回当前线程所对应的线程局部变量。
 *  public void remove()将当前线程局部变量的值删除，目的是为了减少内存的占用，该方法是JDK 5.0新增的方法。需要指出的是，当线程结束后，对应该线程的局部变量将自动被垃圾回收，所以显式调用该方法清除线程的局部变量并不是必须的操作，但它可以加快内存回收的速度。
 *  protected Object initialValue()返回该线程局部变量的初始值，该方法是一个protected的方法，显然是为了让子类覆盖而设计的。这个方法是一个延迟调用方法，在线程第1次调用get()或set(Object)时才执行，并且仅执行1次。ThreadLocal中的缺省实现直接返回一个null。
 *

其实使用真的很简单，线程进来之后初始化一个可以泛型的ThreadLocal对象，之后这个线程只要在remove之前去get，都能拿到之前set的值。他是能做到线程间数据隔离的，所以别的线程使用get（）方法是没办法拿到其他线程的值的，但是有办法可以做到。

## ThreadLocal的底层实现 ##

首先来看看set((Object value)源码

public void set(T value) { 
        Thread t = Thread.currentThread();// 获取当前线程
        ThreadLocalMap map = getMap(t);// 获取ThreadLocalMap对象
        if (map != null) // 校验对象是否为空
            map.set(this, value); // 不为空set
        else
            createMap(t, value); // 为空创建一个map对象
    }

我们可以发现set的源码很简单，主要就是ThreadLocalMap我们需要关注一下，而ThreadLocalMap呢是当前线程Thread一个叫threadLocals的变量中获取的。

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

public class Thread implements Runnable { 
          ……
    
        /* ThreadLocal values pertaining to this thread. This map is maintained * by the ThreadLocal class. */
        ThreadLocal.ThreadLocalMap threadLocals = null;
    
        /* * InheritableThreadLocal values pertaining to this thread. This map is * maintained by the InheritableThreadLocal class. */
        ThreadLocal.ThreadLocalMap inheritableThreadLocals = null;
      
         ……

这里我们基本上可以找到ThreadLocal数据隔离的真相了，每个线程Thread都维护了自己的threadLocals变量，所以在每个线程创建ThreadLocal的时候，实际上数据是存在自己线程Thread的threadLocals变量里面的，别人没办法拿到，从而实现了隔离。

### ThreadLocalMap底层结构 ###

我们可以看到ThreadLocalMap类的源码如下

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;
                }
            }
    
            /** * 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
            
            /** * Set the resize threshold to maintain at worst a 2/3 load factor. */
            private void setThreshold(int len) { 
                threshold = len * 2 / 3;
            }
    
    		ThreadLocalMap(ThreadLocal<?> firstKey, Object firstValue) { 
                table = new Entry[INITIAL_CAPACITY];
                int i = firstKey.threadLocalHashCode & (INITIAL_CAPACITY - 1);
                table[i] = new Entry(firstKey, firstValue);
                size = 1;
                setThreshold(INITIAL_CAPACITY);
            }
    
    		......
    }

大概模型：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzIxNzA2NQ_size_16_color_FFFFFF_t_70]  
ThreadLocal是怎么解决hash冲突的  
我们开发过程中可以一个线程可以有多个TreadLocal来存放不同类型的对象的，但是他们都将放到你当前线程的ThreadLocalMap里，所以肯定要数组来存。  
至于Hash冲突，我们先看一下源码：

private void set(ThreadLocal<?> key, Object value) { 
               Entry[] tab = table;
                int len = tab.length;
                //key的hashCode与数组长度-1按位与运算，得到存储下标i
                int i = key.threadLocalHashCode & (len-1);
                //循环判断下标为i的桶是否空，如果位置i的不为空，而且key不等于entry，那就找下一个空位置，直到为空为止。
                for (Entry e = tab[i];
                     e != null;
                     e = tab[i = nextIndex(i, len)]) { 
                    ThreadLocal<?> k = e.get();
    				//如果位置i不为空，如果这个Entry对象的key正好是即将设置的key，那么就刷新Entry中的value；
                    if (k == key) { 
                        e.value = value;
                        return;
                    }
                    //如果当前位置是空的，就初始化一个Entry对象放在位置i上；
                    if (k == null) { 
                        replaceStaleEntry(key, value, i);
                        return;
                    }
                }
                tab[i] = new Entry(key, value);
                int sz = ++size;
                if (!cleanSomeSlots(i, sz) && sz >= threshold)
                    rehash();
            }

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzIxNzA2NQ_size_16_color_FFFFFF_t_70 1]  
这样的话，在get的时候，也会根据ThreadLocal对象的hash值，定位到table中的位置，然后判断该位置Entry对象中的key是否和get的key一致，如果不一致，就判断下一个位置，set和get如果冲突严重的话，效率还是很低的。  
以下是get的源码：

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 getEntryAfterMiss(ThreadLocal<?> key, int i, Entry e) { 
                Entry[] tab = table;
                int len = tab.length;
    // get的时候一样是根据ThreadLocal获取到table的i值，然后查找数据拿到后会对比key是否相等 if (e != null && e.get() == key)。
                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存在的问题 ###

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzIxNzA2NQ_size_16_color_FFFFFF_t_70 2]  
ThreadLocal在保存的时候会把自己当做Key存在ThreadLocalMap中，正常情况应该是key和value都应该被外界强引用才对，但是现在key被设计成WeakReference弱引用了。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzIxNzA2NQ_size_16_color_FFFFFF_t_70 3]

> 弱引用  
> 只具有弱引用的对象拥有更短暂的生命周期，在垃圾回收器线程扫描它所管辖的内存区域的过程中，一旦发现了只具有弱引用的对象，不管当前内存空间足够与否，都会回收它的内存。

不过，由于垃圾回收器是一个优先级很低的线程，因此不一定会很快发现那些只具有弱引用的对象。

这就导致了一个问题，ThreadLocal在没有外部强引用时，发生GC时会被回收，如果创建ThreadLocal的线程一直持续运行，那么这个Entry对象中的value就有可能一直得不到回收，发生内存泄露。

就比如线程池里面的线程，线程都是复用的，那么之前的线程实例处理完之后，出于复用的目的线程依然存活，所以，ThreadLocal设定的value值被持有，导致内存泄露。

按照道理一个线程使用完，ThreadLocalMap是应该要被清空的，但是现在线程被复用了。  
key不设置成弱引用的话就会造成和entry中value一样内存泄漏的场景

### 解决的方法 ###

在代码的最后使用remove就好了，我们只要记得在使用的最后用remove把值清空就好了。

ThreadLocal<String> localName = new ThreadLocal();
    try { 
        localName.set("张三");
        ……
    } finally { 
        localName.remove();
    }

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzIxNzA2NQ_size_16_color_FFFFFF_t_70]: /images/20230208/73e8cba76d9e4b1caef849bdcca1aa8b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzIxNzA2NQ_size_16_color_FFFFFF_t_70 1]: /images/20230208/0280da672014477eb517c2018ade6563.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzIxNzA2NQ_size_16_color_FFFFFF_t_70 2]: /images/20230208/ff6d10a0156a4e65912faa104a0ba1a1.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzIxNzA2NQ_size_16_color_FFFFFF_t_70 3]: /images/20230208/5cdfb7d1ace445378bda740e4f13e2f1.png