面试之ThreadLocal

落日映苍穹つ 2023-02-11 08:57 9阅读 0赞

在面试环节中，考察"ThreadLocal"的理解十分必要。常用的提问方式如下：  
“知道ThreadLocal吗？”  
“**讲讲你对ThreadLocal的理解**”  
当然了，也有面试官会慢慢引导到这个话题上，  
比如提问“**在多线程环境下，如何防止自己的变量被其它线程篡改**？”  
“**在多线程并发情况下，有一个共享变量，不同线程设置不同值后，各线程只想获取自己设置的值，如何实现**？”

这篇文章主要从以下几个角度来分析理解  
1、ThreadLocal是什么  
2、ThreadLocal源码分析  
3、ThreadLocal内存泄漏问题及解决方案

**一、ThreadLocal是什么**

ThreadLocal即本地线程变量，它填充的变量属于当前线程，**该变量对其他线程而言是隔离的**。ThreadLocal为变量在每个线程中都创建了一个副本，那么每个线程可以访问自己内部的副本变量。  
从数据结构的角度分析，有点像HashMap，可以保存"key : value"键值对，但是一个ThreadLocal只能保存一个，并且各个线程的数据互不干扰。  
ThreadLocal将当前值设置为key。  
使用场景如下：  
（1）**在进行对象跨层传递的时候，使用ThreadLocal可以避免多次传递，打破层次间的约束。**  
（2）**线程间数据隔离。**  
（3）**进行事务操作，用于存储线程事务信息。**  
（4）**数据库连接，Session会话管理。**

ThreadLocal<String> localName = new ThreadLocal();
    localName.set("Aikin_Tony");
    String name = localName.get();

在线程1中初始化了一个ThreadLocal对象localName，并通过set方法，保存了一个值“Aikin\_Tony”，同时在线程1中通过localName.get()可以拿到之前设置的值，但是如果在线程2中，拿到的将是一个null。因为之前也说了，ThreadLocal保证了各个线程的数据互不干扰。

这里分析下set(T value)和get()方法的源码：

public void set(T value) { 
        Thread t = Thread.currentThread();
        ThreadLocalMap map = getMap(t);
        if (map != null)
            map.set(this, value);
        else
            createMap(t, value);
    }
    
    public T get() { 
        Thread t = Thread.currentThread();
        ThreadLocalMap map = getMap(t);
        if (map != null) { 
            ThreadLocalMap.Entry e = map.getEntry(this);
            if (e != null) { 
                @SuppressWarnings("unchecked")
                T result = (T)e.value;
                return result;
            }
        }
        return setInitialValue();
    }
    
    ThreadLocalMap getMap(Thread t) { 
        return t.threadLocals;
    }

可以发现，**每个线程中都有一个ThreadLocalMap数据结构，当执行set方法时，其值是保存在当前线程的threadLocals变量中，执行get方法时，从当前线程的threadLocals变量获取**。

所以在线程1中set的值，对线程2来说是摸不到的，而且在线程2中重新set的话，也不会影响到线程1中的值，**保证了线程之间不会相互干扰。**  
那每个线程中的ThreadLoalMap究竟是什么？  
**二、ThreadLoalMap**

ThreadLoalMap的源码分析  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppa2UxMTIzMQ_size_16_color_FFFFFF_t_70]  
它也是一个**类似HashMap的数据结构，但是在ThreadLocal中，并没实现Map接口**。  
在ThreadLoalMap中，也是初始化一个大小16的**Entry数组**，Entry对象用来保存**每一个key-value键值对**，只不过这里的**key永远都是ThreadLocal对象**，通过ThreadLocal对象的**set方法，把ThreadLocal对象自己当做key，放进ThreadLoalMap中**。

这里需要注意的是，ThreadLoalMap的Entry是继承WeakReference，和HashMap很大的区别是，Entry中没有next字段，所以就不存在链表的情况了。

**解决Hash冲突**

由于ThreadLoalMap没有链表结构，那发生hash冲突了怎么办？  
先看看ThreadLoalMap中插入一个key-value的实现：

private void set(ThreadLocal<?> key, Object value) { 
        Entry[] tab = table;
        int len = tab.length;
        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();
    }

每个ThreadLocal对象都有一个hash值threadLocalHashCode，每初始化一个ThreadLocal对象，hash值就增加一个固定的大小0x61c88647。

在插入过程中，**根据ThreadLocal对象的hash值，定位到table中的位置i，过程如下：**  
1、如果当前位置是空的，那么正好，就初始化一个Entry对象放在位置i上；  
2、不巧，位置i已经有Entry对象了，如果这个Entry对象的key正好是即将设置的key，那么重新设置Entry中的value；  
3、很不巧，位置i的Entry对象，和即将设置的key没关系，那么只能找下一个空位置；

这样的话，在get的时候，也会根据ThreadLocal对象的hash值，定位到table中的位置，然后判断该位置Entry对象中的key是否和get的key一致，如果不一致，就判断下一个位置。

可以发现，set和get如果冲突严重的话，效率很低，因为ThreadLoalMap是Thread的一个属性，所以即使在自己的代码中控制了设置的元素个数，但还是不能控制其它代码的行为。

**内存泄露**

ThreadLocal可能导致内存泄漏，为什么？  
先看看Entry的实现：

static class Entry extends WeakReference<ThreadLocal<?>> { 
        /** The value associated with this ThreadLocal. */
        Object value;
    
        Entry(ThreadLocal<?> k, Object v) { 
            super(k);
            value = v;
        }
    }

通过之前的分析已经知道，当使用ThreadLocal保存一个value时，会在ThreadLocalMap中的数组插入一个Entry对象，按理说key-value都应该以强引用保存在Entry对象中，但**在ThreadLocalMap的实现中，key被保存到了WeakReference对象中。**

这就导致了一个问题，**ThreadLocal在没有外部强引用时，发生GC时会被回收，如果创建ThreadLocal的线程一直持续运行，那么这个Entry对象中的value就有可能一直得不到回收，发生内存泄露**。  
注意：由于**垃圾回收器是一个优先级很低的线程，因此不一定会很快发现那些只具有弱引用的对象。**

**内存泄露解决方案**

**方案一：**  
既然已经发现有内存泄露的隐患，自然有应对的策略，**在调用ThreadLocal的get()、set()可能会清除ThreadLocalMap中key为null的Entry对象**，这样对应的value就没有GC Roots可达了，下次GC的时候就可以被回收，当然如果**调用remove方法，肯定会删除对应的Entry对象**。

**方案二：**  
按照JDK建议将**ThreadLocal变量定义成private static**，这样就一直存在ThreadLocal的强引用，也就能保证任何时候都能通过ThreadLocal的弱引用访问到Entry的value值，进而清除掉。

如果使用ThreadLocal的set方法之后，没有显示的调用remove方法，就有可能发生内存泄露，所以养成良好的编程习惯十分重要，使用完**ThreadLocal之后，记得调用remove方法**。

ThreadLocal<String> localName = new ThreadLocal();
    try { 
        localName.set("Aikin_Tony");
        // 其它业务逻辑
    } finally { 
        localName.remove();
    }

原文链接：  
https://blog.csdn.net/cowbin2012/article/details/89792106

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppa2UxMTIzMQ_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/20200522181511296.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppa2UxMTIzMQ==,size_16,color_FFFFFF,t_70