ThreadLocal源码解析

最新推荐文章于 2023-03-07 20:44:57 发布

遇见更好的自己、

最新推荐文章于 2023-03-07 20:44:57 发布

阅读量514

点赞数

分类专栏： Java基础文章标签： java 内存泄漏

本文链接：https://blog.csdn.net/weixin_44399827/article/details/118197226

版权

Java基础专栏收录该内容

31 篇文章 0 订阅

订阅专栏

ThreadLocal主要是用于隔离线程使用：隔离线程，

一个广泛的应用场景是：登录用户的隔离，通常一个请求一个线程处理一个登录用户信息，线程AB分别处理张三和李四的登录信息、如果使用ThreadLocal就能很好做好隔离，A只能访问到张三的用户信息。B只能访问李四的线程信息、而不会乱套：

接下我们来看源码看ThreadLocal是如何实现的线程隔离的:

public class ThreadLocalTest {
 
    private static ThreadLocal<String> threadLocal = new ThreadLocal<>();
 
    public static void main(String[] args) {
        threadLocal.set("张三")
        System.out.println(get()); 
    }
 
}

上面是 ThreadLocal一个很简单的使用例子：

首先看ThreadLocal的构造方法默认一个ThreadLocal对象

  public ThreadLocal() {
    }

接下来看set方法

    public void set(T value) {
        Thread t = Thread.currentThread();
        ThreadLocalMap map = getMap(t);
        if (map != null)
            map.set(this, value);
        else
            createMap(t, value);
    }

    ThreadLocalMap getMap(Thread t) {
        return t.threadLocals;
    }

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

上面的set方法：首先获取到当前执行的线程Thread对象，Thread对象有个成员变量ThreadLocalMap，Map中的Key和value：key为threadLocal对象 value为要存入的线程需要隔离的数据。看到这里其实大家也大概清楚了，Thread是如何做线程隔离的。每一个线程都是一个成员变量ThreadLocalMap ：threadLocal作为lkey：value是要隔离的数据用值

看到这里可能有同学会问：

1、如何ThreadLocalMap发生hash碰撞怎么处理

2、为何ThreadLocalMap的key值不用Thread对象。这样是不是更好理解。线程和value一对一的绑定。

3、Thread作为一个比较持久的对象，在ThreadLocalMap中引用了threadLocal对象，那么这个threadLocal对象是否为存在内存泄漏的情况，一直不会被GC清理掉。

接下来我们带着问题一个一个的看，首先看第一个问题：

set方面的源码：

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];
                //如果tab[i]中有值说明发行了hash碰撞。
                 e != null; 
              //找打数组下一个槽位的值
                 e = tab[i = nextIndex(i, len)]) {
                ThreadLocal<?> k = e.get();
                 //如果下一个槽位的值和当前值相等，那么就替换，相等于刷新值 
                if (k == key) {
                    e.value = value;
                    return;
               //如果下一个槽位的值和当前值相等，那么就把key值放到下一个槽位
                if (k == null) {
                    replaceStaleEntry(key, value, i);
                    return;
                }
            }

            tab[i] = new Entry(key, value);
            int sz = ++size;
            if (!cleanSomeSlots(i, sz) && sz >= threshold)
                rehash();
        }

所以第一个问题：如果发生冲突，ThreadlocalMap直接往后找相邻的下一个节点，如果相邻节点为空，直接存进去，如果不为空，继续往后找，直到找到空的，把元素放进去，或者元素个数超过数组长度阈值，进行扩容。

问题2：

其实我们可以思考这样一个问题，Thread对象是唯一的。一个线程即一个Thread对象要隔离的数据不止一个怎么办。这就是为什么不能用Thread对象作为key的原因。因为没法扩展多个要隔离的数据的问题、

问题3：

ThreadLocalMap的源码：

      ThreadLocalMap(ThreadLocal<?> firstKey, Object firstValue) {
          INITIAL_CAPACITY 默认大小为16
           table = new Entry[INITIAL_CAPACITY];
            // firstKey.threadLocalHashCode 求得ThreadLocal对象的HashCode值 并取模15
            int i = firstKey.threadLocalHashCode & (INITIAL_CAPACITY - 1);
            table[i] = new Entry(firstKey, firstValue);
            size = 1;
            setThreshold(INITIAL_CAPACITY);
        }

        static class Entry extends WeakReference<ThreadLocal<?>> {
            Object value;

            Entry(ThreadLocal<?> k, Object v) {
                super(k);
                value = v;
            }
        }

通过上面源码可以发现：ThreadLocalMap中的Threadlocal对象是弱引用：

我们来回顾下：Java的四种引用：

强引用是使用最普遍的引用。如果一个对象具有强引用，那垃圾回收器绝不会回收它，当内存空间不足时，Java虚拟机宁愿抛出OutOfMemoryError错误，使程序异常终止，也不会靠随意回收具有强引用的对象来解决内存不足的问题。
如果一个对象只具有软引用，则内存空间充足时，垃圾回收器就不会回收它；如果内存空间不足了，就会回收这些对象的内存。
弱引用与软引用的区别在于：只具有弱引用的对象拥有更短暂的生命周期。在垃圾回收器线程扫描内存区域时，一旦发现了只具有弱引用的对象，不管当前内存空间足够与否，都会回收它的内存。不过，由于垃圾回收器是一个优先级很低的线程，因此不一定会很快发现那些只具有弱引用的对象。
虚引用顾名思义，就是形同虚设。与其他几种引用都不同，虚引用并不会决定对象的生命周期。如果一个对象仅持有虚引用，那么它就和没有任何引用一样，在任何时候都可能被垃圾回收器回收。

弱引用当发生GC时，不管内存是够够用。会立马回收这个对象：

我们回过头来看整个引用链路：

首先 private static ThreadLocal<String> threadLocal = new ThreadLocal<>();

这里使用了一个强引用堆中的threadLocal对象：

然后set的时候。ThreadLocalMap中存在一个弱引用的threadLocal对象：

可以看得出。只要threadLocal不赋值为空的情况下：threadLocal一直有一个强引用存在：

GC在回收的时候，是回收不掉这个对象的，就是为什么ThreadLocal会存在内存泄漏的问题：

所以我们在使用ThreadLocal对象的时候一定要记得在finnaly中remove掉应用，这样就不会造成内存泄漏。

写到这里有的同学可能就会问：那为什么ThreadLocalMap中要用弱引用勒？

想想如果ThreadLocalMap用的是强引用Thread对象是一个持久化的对象很难被回收、一旦是强引用，那么ThreadLocalMap中就一直会有值，一直不会被清理掉、这也是设计的时候避免造成内存泄漏的一个巧妙设计。

为什么Entry的key（ThreadLocal）要设置成弱引用？

ps：这里我们可以看到，这个弱引用的引用者是ThreadLocal，也就是这个Entry的key

我们知道，弱引用有一个特点：当VM在GC的时候，如果这个对象只有弱引用指向，则该对象不管是否存活，都要被回收

那我们的Entry什么情况下会产生这个情况呢？答案就是我们外部的ThreadLocal的生命周期结束了，因为这样就只有软引用定义的引用者（也就是这个ThreadLocal，在这里是Entry的key）在指向这个对象；如果ThreadLocal的生命周期没结束的话，这个ThreadLocal肯定会有强引用在指向的

如果一旦发生ThreadLocal生命周期结束，但是又没有清空Entry（Entry没被清空，Entry的key也就是ThreadLocal还在使用）这种情况，并且又是强引用，会发生什么情况？就会发生如果这个线程不消亡，这个对象就回收不掉的情况，但是这个对象又是可达的（有Entry的key指向），这就产生了可达但不使用的情况，就是我们说的内存泄漏

但是如果我们设置成是弱引用，就能尽可能避免这个问题（线程执行完但是Entry没被清，下一次GC的时候，就能把这个对象回收了）

ps:这里的value是不能被定义成弱引用的，因为外部没有强引用指向它，但是key（ThreadLocal）用强引用，这点用ThreadLocal本身作为key的设计还是挺巧妙的

问题到这里，可能又有人有行的问题了——既然Entry里只有key被设置成弱引用，value没有设置，那岂不是value会很容易产生内存泄漏的问题？（因为这时候key被回收了，也就是key变成了null，但是value还是强引用，对象还在堆里，并且可达不使用，就是在ThreadLocalMap的Entry里产生了一堆key为null的东西）

的确是这样的，但是这个问题，jdk的设计者在设计的时候就在一定程度上进行了缓解——我们在调用ThreadLocal的get/set/remove的时候，底层源码会自动地把这一堆key为null的东西删除了，以便下一次GC把value回收掉

注上参考文档：

一个ThreadLocal和面试官大战30个回合

ThreadLocal的使用及其原理_mweibiao的博客-CSDN博客_threadlocal使用