ThreadLocal原理及使用场景

ゞ浴缸里的玫瑰 2024-03-30 16:20 63阅读 0赞

## ThreadLocal ##

ThreadLocal意为线程本地变量，用于解决多线程并发时访问共享变量的问题。

所谓的共享变量指的是在堆中的实例、静态属性和数组；对于共享数据的访问受Java的内存模型（JMM）的控制，其模型如下：

![e716ff96d8cd5f1869c6aa61305ede5b.png][]

【参考：《Java并发编程的艺术》P22】

每个线程都会有属于自己的本地内存，在堆（也就是上图的主内存）中的变量在被线程使用的时候会被复制一个副本线程的本地内存中，当线程修改了共享变量之后就会通过JMM管理控制写会到主内存中。

很明显，在多线程的场景下，当有多个线程对共享变量进行修改的时候，就会出现线程安全问题，即数据不一致问题。常用的解决方法是对访问共享变量的代码加锁（synchronized或者Lock）。但是这种方式对性能的耗费比较大。在JDK1.2中引入了ThreadLocal类，来修饰共享变量，使每个线程都单独拥有一份共享变量，这样就可以做到线程之间对于共享变量的隔离问题。

当然锁和ThreadLocal使用场景还是有区别的，具体区别如下：

![ed1ed3193aa9d862a43cb415a21231c5.png][]

## 一、ThreadLocal的使用及原理 ##

### 1.1 使用 ###

一般都会将ThreadLocal声明成一个静态字段，同时初始化如下：

static ThreadLocal<Object> threadLocal = new ThreadLocal<>();

其中Object就是原本堆中共享变量的数据。

例如，有个User对象需要在不同线程之间进行隔离访问，可以定义ThreadLocal如下：

public class Test {
        static ThreadLocal<User> threadLocal = new ThreadLocal<>();
    }

常用的方法  
set(T value)：设置线程本地变量的内容。  
get()：获取线程本地变量的内容。  
remove()：移除线程本地变量。注意在线程池的线程复用场景中在线程执行完毕时一定要调用remove，避免在线程被重新放入线程池中时被本地变量的旧状态仍然被保存。

public class Test {
        static ThreadLocal<User> threadLocal = new ThreadLocal<>();
        
        public void m1(User user) {
            threadLocal.set(user);
        }
        
        public void m2() {
            User user = threadLocal.get();
            // 使用
            
            // 使用完清除
            threadLocal.remove();
        }
    }

### 1.2 原理 ###

那么如何究竟是如何实现在每个线程里面保存一份单独的本地变量呢？首先，在Java中的线程是什么呢？是的，就是一个Thread类的实例对象！而一个实例对象中实例成员字段的内容肯定是这个对象独有的，所以我们也可以将保存ThreadLocal线程本地变量作为一个Thread类的成员字段，这个成员字段就是：

/* ThreadLocal values pertaining to this thread. This map is maintained
     * by the ThreadLocal class. */
    ThreadLocal.ThreadLocalMap threadLocals = null;

是一个在ThreadLocal中定义的Map对象，保存了该线程中的所有本地变量。ThreadLocalMap中的Entry的定义如下：

static class Entry extends WeakReference<ThreadLocal<?>> {
        /** The value associated with this ThreadLocal. */
        Object value;
        // key为一个ThreadLocal对象，v就是我们要在线程之间隔离的对象
        Entry(ThreadLocal<?> k, Object v) {
            super(k);
            value = v;
        }
    }

ThreadLocalMap和Entry都在ThreadLocal中定义。

ThreadLocal::set方法的原理

set方法的源码如下：

public void set(T value) {
        // 获取当前线程
        Thread t = Thread.currentThread();
        // 获取当前线程的threadLocals字段
        ThreadLocalMap map = getMap(t);
        // 判断线程的threadLocals是否初始化了
        if (map != null) {
            map.set(this, value);
        } else {
            // 没有则创建一个ThreadLocalMap对象进行初始化
            createMap(t, value);
        }
    }

createMap方法的源码如下：

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

map.set方法的源码如下:

/**
    * 往map中设置ThreadLocal的关联关系
    * set中没有使用像get方法中的快速选择的方法，因为在set中创建新条目和替换旧条目的内容一样常见，
    * 在替换的情况下快速路径通常会失败（对官方注释的翻译）
    */
    private void set(ThreadLocal<?> key, Object value) {
        // map中就是使用Entry[]数据保留所有的entry实例
        Entry[] tab = table;
        int len = tab.length;
        // 返回下一个哈希码，哈希码的产生过程与神奇的0x61c88647的数字有关
        int i = key.threadLocalHashCode & (len-1);
    
        for (Entry e = tab[i]; e != null; e = tab[i = nextIndex(i, len)]) {
            ThreadLocal<?> k = e.get();
            if (k == key) {
                // 已经存在则替换旧值
                e.value = value;
                return;
            }
            if (k == null) {
                // 在设置期间清理哈希表为空的内容，保持哈希表的性质
                replaceStaleEntry(key, value, i);
                return;
            }
        }
        tab[i] = new Entry(key, value);
        int sz = ++size;
        // 扩容逻辑
        if (!cleanSomeSlots(i, sz) && sz >= threshold)
            rehash();
    }

Thread::get方法的原理

public T get() {
        Thread t = Thread.currentThread();
        ThreadLocalMap map = getMap(t);
        if (map != null) {
            // 获取ThreadLocal对应保留在Map中的Entry对象
            ThreadLocalMap.Entry e = map.getEntry(this);
            if (e != null) {
                @SuppressWarnings("unchecked")
                // 获取ThreadLocal对象对应的值
                T result = (T)e.value;
                return result;
            }
        }
        // map还没有初始化时创建map对象，并设置null，同时返回null
        return setInitialValue();
    }

ThreadLocal::remove()方法原理

public void remove() {
        ThreadLocalMap m = getMap(Thread.currentThread());
        // 键在直接移除
        if (m != null) {
            m.remove(this);
        }
    }

ThreadLocalMap的类结构体系如下：

![275ccd39f6903e160cf622a0a142b2f8.png][]

## 1.3 ThreadLocal设计 ##

在JDK早期的设计中，每个ThreadLocal都有一个map对象，将线程作为map对象的key，要存储的变量作为map的value，但是现在已经不是这样了。  
JDK8之后，每个Thread维护一个ThreadLocalMap对象，这个Map的key是ThreadLocal实例本身，value是存储的值要隔离的变量，是泛型，其具体过程如下：  
每个Thread线程内部都有一个Map（ThreadLocalMap::threadlocals）;  
Map里面存储ThreadLocal对象（key）和线程的变量副本（value）;  
Thread内部的Map由ThreadLocal维护，由ThreadLocal负责向map获取和设置变量值;  
对于不同的线程，每次获取副本值时，别的线程不能获取当前线程的副本值，就形成了数据之间的隔离。  
JDK8之后设计的好处在于：

每个Map存储的Entry的数量变少，在实际开发过程中，ThreadLocal的数量往往要少于Thread的数量，Entry的数量减少就可以减少哈希冲突。  
当Thread销毁的时候，ThreadLocalMap也会随之销毁，减少内存使用，早期的ThreadLocal并不会自动销毁。  
使用ThreadLocal的好处

保存每个线程绑定的数据，在需要的地方可以直接获取，避免直接传递参数带来的代码耦合问题；  
各个线程之间的数据相互隔离却又具备并发性，避免同步方式带来的性能损失。

## 二、ThreadLocal内存泄露问题 ##

内存泄露问题：指程序中动态分配的堆内存由于某种原因没有被释放或者无法释放，造成系统内存的浪费，导致程序运行速度减慢或者系统奔溃等严重后果。内存泄露堆积将会导致内存溢出。

ThreadLocal的内存泄露问题一般考虑和Entry对象有关，在上面的Entry定义可以看出ThreadLocal::Entry被弱引用所修饰。**JVM会将弱引用修饰的对象在下次垃圾回收中清除掉。**这样就可以实现ThreadLocal的生命周期和线程的生命周期解绑。但实际上并不是使用了弱引用就A会发生内存泄露问题，考虑下面几个过程：

1.使用强引用

![f12e17f0abc801c642d471b150d80796.png][]

当ThreadLocal Ref被回收了，由于在Entry使用的是强引用，在Current Thread还存在的情况下就存在着到达Entry的引用链，无法清除掉ThreadLocal的内容，同时Entry的value也同样会被保留；也就是说就算使用了强引用仍然会出现内存泄露问题。

2.使用弱引用

![2f5a5cf3fc9bb4aa87adcca9a7a2eb0d.png][]

当ThreadLocal Ref被回收了，由于在Entry使用的是弱引用，因此在下次垃圾回收的时候就会将ThreadLocal对象清除，这个时候Entry中的KEY=null。但是由于ThreadLocalMap中任然存在Current Thread Ref这个强引用，因此Entry中value的值任然无法清除。还是存在内存泄露的问题。

由此可以发现，使用ThreadLocal造成内存泄露的问题是因为：ThreadLocalMap的生命周期与Thread一致，如果不手动清除掉Entry对象的话就可能会造成内存泄露问题。因此，需要我们在每次在使用完之后需要手动的remove掉Entry对象。

那么为什么使用弱引用？

避免内存泄露的两种方式：使用完ThreadLocal，调用其remove方法删除对应的Entry或者使用完ThreadLocal，当前Thread也随之运行结束。第二种方法在使用线程池技术时是不可以实现的。

所以一般都是自己手动调用remove方法，调用remove方法弱引用和强引用都不会产生内存泄露问题，使用弱引用的原因如下：

在ThreadLocalMap的set/getEntry中，会对key进行判断，如果key为null，那么value也会被设置为null，这样即使在忘记调用了remove方法，当ThreadLocal被销毁时，对应value的内容也会被清空。多一层保障！

总结：存在内存泄露的有两个地方：ThreadLocal和Entry中Value；最保险还是要注意要自己及时调用remove方法！！！

## 三、ThreadLocal的应用场景 ##

场景一：在重入方法中替代参数的显式传递

假如在我们的业务方法中需要调用其他方法，同时其他方法都需要用到同一个对象时，可以使用ThreadLocal替代参数的传递或者static静态全局变量。这是因为使用参数传递造成代码的耦合度高，使用静态全局变量在多线程环境下不安全。当该对象用ThreadLocal包装过后，就可以保证在该线程中独此一份，同时和其他线程隔离。

例如在Spring的@Transaction事务声明的注解中就使用ThreadLocal保存了当前的Connection对象，避免在本次调用的不同方法中使用不同的Connection对象。

场景二：全局存储用户信息

可以尝试使用ThreadLocal替代Session的使用，当用户要访问需要授权的接口的时候，可以现在拦截器中将用户的Token存入ThreadLocal中；之后在本次访问中任何需要用户用户信息的都可以直接冲ThreadLocal中拿取数据。例如自定义获取用户信息的类AuthHolder：

public class AuthNHolder {
        private static final ThreadLocal<Map<String,String>> threadLocal = new ThreadLocal<>();
        public static void map(Map<String,String> map){
            threadLocal.set(map);
        }
        // 获取用户id
        public static String userId(){
            return get("userId");
        }
        // 根据键值获取对应的信息
        public static String get(String key){
            Map<String,String> map = getMap();
            return map.get(key);
        }
        // 用完清空ThreadLocal
        public static void clear(){
            threadLocal.remove();
        }
    }

备注：ThreadLocal里面封装的value只是一个例子，根据具体业务需求改就行了。

场景三：解决线程安全问题

依赖于ThreadLocal本身的特性，对于需要进行线程隔离的变量可以使用ThreadLocal进行封装。

## 四、总结 ##

ThreadLocal更像是对其他类型变量的一层包装，通过ThreadLocal的包装使得该变量可以在线程之间隔离和当前线程全局共享。

线程的隔离性和变量的线程全局共享性得益于在每个Thread类中的threadlocals字段。（从类实例对象的角度抽象的去看Java中的线程！！！）

ThreadLocalMap中Entry的Key不管是否使用弱引用都有内存泄露的可能。引起内存泄露主要在于ThreadLocal对象和Entry中的Value对象，因此要确保每次使用完之后都remove掉Entry！

[e716ff96d8cd5f1869c6aa61305ede5b.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/30/2ed8674023f44893a5dae2d7b8763137.png
[ed1ed3193aa9d862a43cb415a21231c5.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/30/1436d90673234502a0275c5a2c9c2ff6.png
[275ccd39f6903e160cf622a0a142b2f8.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/30/2cbd9617dd2c40e491e9fa4d9902dcfc.png
[f12e17f0abc801c642d471b150d80796.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/30/f4072e75f5e9408492abe5d6414d3719.png
[2f5a5cf3fc9bb4aa87adcca9a7a2eb0d.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/30/d69517a968914ae390b89f53cb3fc490.png