ThreadLocal浅析

什么是ThreadLocal：

ThreadLocal 提供了线程本地的实例。 它与普通变量的区别在于，每个使用该变量的线程都会初始化一个完全独立的实例副本。 ThreadLocal 变量通常被 private static 修饰。 当一个线程结束时，它所使用的所有ThreadLocal 相对的实例副本都可被回收。

ThreadLocal一般用法介绍

首先声明，ThreadLocal只会出现在多线程编程中。单线程中完全用不到这个玩意儿。
首先我们从它的用法入手?？垂俜酵萍鑫颐堑挠梅ǎ?/p> 

import java.util.concurrent.atomic.AtomicInteger;

public class ThreadId {
     // Atomic integer containing the next thread ID to be assigned
     private static final AtomicInteger nextId = new AtomicInteger(0);

     // Thread local variable containing each thread's ID
     private static final ThreadLocal<Integer> threadId =
         new ThreadLocal<Integer>() {
             @Override protected Integer initialValue() {
                 return nextId.getAndIncrement();
         }
     };

     // Returns the current thread's unique ID, assigning it if necessary
     public static int get() {
         return threadId.get();
     }
 }

官方推荐我们把ThreadLocal用static final修饰，有个解释挺好的，因为在ThreadLocalMap中ThreadLocal是作为key-value中的Key来用的，如果ThreadLocal可以修改，那我们拿着threadLocal去map中找的时候就找不到了，所以需要用final来修饰。
上面的推荐用法其实并不能说明什么问题，我们用另外一个例子来说明：

public class testThreadLocal {
    private int repeat = 20;
    private static final AtomicInteger local = new AtomicInteger(0);

    private static final ThreadLocal<Integer> threadLocal = ThreadLocal.withInitial(() -> 0);

    public void test() {
        Thread t1 = new Thread(() -> {
            LogUtil.Companion.d("ThreadLocal线程1->" + repeat1(threadLocal));
        });
        Thread t2 = new Thread(() -> {
            LogUtil.Companion.d("ThreadLocal线程2->" + repeat1(threadLocal));

        });
        Thread t3 = new Thread(() -> {
            LogUtil.Companion.d("AtomicInteger线程3->" + repeat2(local));
        });
        Thread t4 = new Thread(() -> {
            LogUtil.Companion.d("AtomicInteger线程4->" + repeat2(local));
        });
        t1.start();
        t2.start();
        t3.start();
        t4.start();
    }

    private String repeat1(ThreadLocal<Integer> threadLocal) {
        int x = 0;
        StringBuilder sb = new StringBuilder();
        while (x < repeat) {
            int index = threadLocal.get();
            threadLocal.set(++index);
            x++;
            sb.append(index).append(" ");
        }
        return sb.toString();
    }

    private String repeat2(AtomicInteger local) {
        int x = 0;
        StringBuilder sb = new StringBuilder();
        while (x < repeat) {
            local.getAndAdd(1);
            x++;
            sb.append(local.get()).append(" ");
        }
        return sb.toString();
    }
}

输出结果：
ThreadLocal线程1->1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
ThreadLocal线程2->1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
AtomicInteger线程3->1 3 5 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 40
AtomicInteger线程4->2 4 6 7 8 10 12 14 16 18 20 22 24 26 28 30 32 34 36 38

很明显能看出来ThreadLocal的作用了，即使我们线程1和线程2用了同一个ThreadLocal，他们的结果是完全没有互相影响的。反观线程3和线程4共用了一个AtomicInteger，他们的结果是会互相影响的。
注：如果ThreadLocal存储的是Object，两个线程不要使用同一个对象，因为ThreadLocal并没有对对象做深拷贝，所以如果使用同一个对象，还是会导致多线程的竞争问题。

ThreadLocal源码浅析

我们来看下ThreadLocal的源码找一下原因：

//ThreadLocal
    protected T initialValue() {
        return null;
    }

    public static <S> ThreadLocal<S> withInitial(Supplier<? extends S> supplier) {
        return new SuppliedThreadLocal<>(supplier);
    }

    public ThreadLocal() {
    }
...
    private T setInitialValue() {
        T value = initialValue(); // 获取初始值
        Thread t = Thread.currentThread(); // 获取当前线程
        ThreadLocalMap map = getMap(t); //获取ThreadLocalMap
        if (map != null)
            map.set(this, value); //存在则赋值
        else
            createMap(t, value); // 不存在则初始化ThreadLocalMap
        return value;
    }

    static final class SuppliedThreadLocal<T> extends ThreadLocal<T> {
        private final Supplier<? extends T> supplier;
        SuppliedThreadLocal(Supplier<? extends T> supplier) {
            this.supplier = Objects.requireNonNull(supplier);
        }
        @Override
        protected T initialValue() {
            return supplier.get();
        }
    }

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

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

    static class ThreadLocalMap {
...
    }

我们先看构造方法，默认构造方法什么都没做。我们看有个默认值T initialValue(){return null;} ，就是说如果仅仅是调用
static final ThreadLocal<Integer> threadLocal = new ThreadLocal();
来构造ThreadLocal的话，然后直接调用get()的话，会直接返回null。所以可以用官方推荐的构造方法来初始化一个initialValue。
我们看setInitialValue方法，这里先取得当前的线程，然后得到线程的一个叫做threadLocals的参数，这是什么呢？我们去Thread的源码里面看(先只关注threadLocals)：

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

ThreadLocalMap是ThreadLocal的一个静态内部类，每个Thread都持有一个ThreadLocalMap变量叫做threadLocals，这个threadLocals是在ThreadLocal set的时候初始化的。
其实ThreadLocal正式给我们用的方法就两个，一个get()，一个set()。先看set():

//ThreadLocal
    public void set(T value) {
        Thread t = Thread.currentThread(); // 获取当前的Thread
        ThreadLocalMap map = getMap(t); // 获取当前thread的ThreadLocalMap
        if (map != null) // 如果map不为null，设置到map中去
            map.set(this, value);
        else
            createMap(t, value); //初始化Thread的ThreadLocalMap
    }

    void createMap(Thread t, T firstValue) {
        t.threadLocals = new ThreadLocalMap(this, firstValue);// 给当前Thread的threadLocals初始化
    }

我们来看get()方法：

//ThreadLocal
    public T get() {
        Thread t = Thread.currentThread();// 获取当前的Thread
        ThreadLocalMap map = getMap(t); // 获取当前thread的threadLocals。
        if (map != null) { // 如果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;
    }

其实很明显，ThreadLocal就是围绕在ThreadLocal、ThreadLocalMap、Thread这三个类完成的线程独立的操作。
其中ThreadLocalMap是ThreadLocal的一个静态内部类，我们知道静态内部类除了是属于外部类以外，其实跟外部类没啥关系，只是说定义在了一个类里面，有了一个所谓逻辑上的归属关系。
我们看一下ThreadLocalMap的代码：

 static class ThreadLocalMap {
        //K-V结构的entry
        static class Entry extends WeakReference<ThreadLocal<?>> {
            /** The value associated with this ThreadLocal. */
            Object value;

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

        private static final int INITIAL_CAPACITY = 16;
        private Entry[] table;
...

ThreadLocalMap则是实现了一个K-V机构的Map，Key是ThreadLocal，Value是Object。原始大小是16。并且Entry是一个弱引用，只被弱引用持有的对象会在GC的时候被回收掉，这样不再被使用的 ThreadLocal 可以被检查出来并清除掉。Map在做操作的时候也会有Entry被回收掉的判断。
ThreadLocal的get(),set()其实最重要的方法还是调用了ThreadLocalMap的get()set()。下面看get()代码：

//ThreadLocalMap
        private Entry getEntry(ThreadLocal<?> key) {//Thread的get()其实调用了ThreadLocalMap的getEntry
            int i = key.threadLocalHashCode & (table.length - 1); // 获得应该存放的index
            Entry e = table[i];
            if (e != null && e.get() == key)
                return e; //正好就是要查找的index
            else
                return getEntryAfterMiss(key, i, e); // 当前不是对应的key或者key为null
        }

//所谓的开放寻址
        private Entry getEntryAfterMiss(ThreadLocal<?> key, int i, Entry e) {
            Entry[] tab = table;
            int len = tab.length;

            while (e != null) {
                ThreadLocal<?> k = e.get();
                if (k == key) // 找到key对应的entry
                    return e;
                if (k == null)
                    expungeStaleEntry(i); // 擦除此key对应的entry
                else
                    i = nextIndex(i, len); //继续向下找
                e = tab[i];
            }
            return null;
        }

我们浏览一遍ThreadLocalMap的代码就知道，其实这是一个专门为ThreadLocal设计的HashMap，很多地方我们都能看到HashMap的影子，第一个不一样的地方我们现在其实看到了，就是取index的方式不一样.
HashMap的存储位置由 Key的哈希值的高16位的后x位和低16位的后x位异或得出(x是hashmap数组长度length-1的二进制位数)。
ThreadLocalMap是怎么获取的呢？

//ThreadLocalMap
int i = key.threadLocalHashCode & (table.length - 1);

//ThreadLocal
    private final int threadLocalHashCode = nextHashCode();
/**
     * The difference between successively generated hash codes - turns
     * implicit sequential thread-local IDs into near-optimally spread
     * multiplicative hash values for power-of-two-sized tables.
     */
private static final int HASH_INCREMENT = 0x61c88647;
private static int nextHashCode() {
        return nextHashCode.getAndAdd(HASH_INCREMENT);
    }

这里有个魔数0x61c88647，依次相加。然后跟length-1取模，就散列了。呃~~~~ 就很神奇~这么神奇的事情，我们当然要去试一下子，16个坑，依次加0x61c88647，取模出结果：

int x = HASH_INCREMENT;
        for (int i = 0; i <= 16; i++) {
            LogUtil.Companion.d(i + "   " + (x & 15) + " -- " + Integer.toBinaryString(x & 15) + " -- " + Integer.toBinaryString(x));
            x += HASH_INCREMENT;
        }
//结果：
//            1   14 -- 1110 -- 11000011100100010000110010001110
//            2   5 -- 101 -- 100101010110011001001011010101
//            3   12 -- 1100 -- 10000111001000100001100100011100
//            4   3 -- 11 -- 11101000111010101001111101100011
//            5   10 -- 1010 -- 1001010101100110010010110101010
//            6   1 -- 1 -- 10101100011110111010101111110001
//            7   8 -- 1000 -- 1110010001000011001000111000
//            8   15 -- 1111 -- 1110000000011001011100001111111
//            9   6 -- 110 -- 11010001110101010011111011000110
//            10   13 -- 1101 -- 110011100111011100010100001101
//            11   4 -- 100 -- 10010101011001100100101101010100
//            12   11 -- 1011 -- 11110111001011101101000110011011
//            13   2 -- 10 -- 1011000111101110101011111100010
//            14   9 -- 1001 -- 10111010101111111101111000101001
//            15   0 -- 0 -- 11100100010000110010001110000
//            16   7 -- 111 -- 1111110010100001110101010110111

试完我们就只能惊呼，数学真神奇?。?！数学不好，解释不了。这玩意儿得等我沉淀两年再求甚解，暂时略过 ~

其实这个地方threadLocalHashCode的赋值也很巧妙，threadLocalHashCode是一个final的成员变量，但是赋值的nextHashCode()是一个静态方法，这个方法又调用了一个静态变量nextHashCode执行了getAndAdd()的自增方法。我们都知道静态变量就是类变量，不论是加载还是初始化都是远远早于成员变量的。而且这个结构相当于多个ThreadLocal共享了一个静态的nextHashCode，只不过是在调用的时候自增一下。这样就能保证每次能自增+1，并且后面调用都能在前面自增结束的基础上再操作。
我们回来继续看get()，看到一幅图画的很好，能表明介绍到的一些对象之间的引用关系图，实线表示强引用，虚线表示弱引用：

引用关系

图片引自https://www.cnblogs.com/xzwblog/p/7227509.html
也就能解释为什么get的时候会找不到。Map里面的Entry持有的是一个ThreadLocal的弱引用，相当于如果正常情况下ThreadLocal会被两个引用持有：

  1. 上面用户按照java推荐使用static final声明的ThreadLocal引用。
  2. thread初始化或者调用set后ThreadLocalMap的Entry持有的ThreadLocal的弱引用。

所以正常情况下线程在正常使用ThreadLocal的时候肯定没有问题，ThreadLocal不会被回收。但如果这个ThreadLocal用完了被删掉的时候ThreadLocal就只有ThreadLocalMap的Entry的弱引用了，这个时候只要GC就会被回收掉，回收掉之后key就变成了null。这个时候这个Entry的Key就是null，而Value还是之前保存的Object。而这个Entry是强引用，是不会被自动回收的，所以就需要自己回收。
在get set的时候都有操作从i开始朝后找，找到null就回收掉。但是我们想一想，其实很多时候都不会调用get set了，所以很多时候需要自己调用remove()方法去回收。

那我们来理一下，每个Thread都有一个ThreadLocalMap的对象叫做threadLocals，当User调用Thread的set(),get()方法的时候会找到当前类的threadLocals，threadLocals中把ThreadLocal当做key来存放需要存放的Object。get的时候亦然。
所以每个thread都有一个Map来存放Thread对应的Object，所以多个Thread即使使用同一个ThreadLocal都不会相互影响。

总结：

  1. ThreadLocal只会用在多线程中，当前线程独立访问，推荐使用static final 修饰
  2. Thread中持有一个ThreadLocalMap，ThreadLocalMap中持有多个<ThreadLocal,Object>的Entry。
  3. Entry中ThreadLocal被弱引用持有，可能会被回收，ThreadLocalMap在get() set()的时候会删掉所有的已经被回收的ThreadLocal的Object，但推荐单独使用remove()删除。
  4. 取index使用了魔数0x61c88647，递加就能实现均匀，太神奇，解释不了。
最后编辑于 ：
?著作权归作者所有,转载或内容合作请联系作者
  • 人面猴
    序言：七十年代末，一起剥皮案震惊了整个滨河市，随后出现的几起案子，更是在滨河造成了极大的恐慌，老刑警刘岩，带你破解...
    沈念sama阅读 214,029评论 6赞 493
  • 死咒
    序言：滨河连续发生了三起死亡事件，死亡现场离奇诡异，居然都是意外死亡，警方通过查阅死者的电脑和手机，发现死者居然都...
    沈念sama阅读 91,238评论 3赞 388
  • 救了他两次的神仙让他今天三更去死
    文/潘晓璐 我一进店门，熙熙楼的掌柜王于贵愁眉苦脸地迎上来，“玉大人，你说我怎么就摊上这事?！?“怎么了？”我有些...
    开封第一讲书人阅读 159,576评论 0赞 349
  • 道士缉凶录：失踪的卖姜人
    文/不坏的土叔 我叫张陵，是天一观的道长。 经常有香客问我，道长，这世上最难降的妖魔是什么？ 我笑而不...
    开封第一讲书人阅读 57,214评论 1赞 287
  • ?港岛之恋（遗憾婚礼）
    正文 为了忘掉前任，我火速办了婚礼，结果婚礼上，老公的妹妹穿的比我还像新娘。我一直安慰自己，他们只是感情好，可当我...
    茶点故事阅读 66,324评论 6赞 386
  • 恶毒庶女顶嫁案：这布局不是一般人想出来的
    文/花漫 我一把揭开白布。 她就那样静静地躺着，像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上，一...
    开封第一讲书人阅读 50,392评论 1赞 292
  • 城市分裂传说
    那天，我揣着相机与录音，去河边找鬼。 笑死，一个胖子当着我的面吹牛，可吹牛的内容都是我干的。 我是一名探鬼主播，决...
    沈念sama阅读 39,416评论 3赞 412
  • 双鸳鸯连环套：你想象不到人心有多黑
    文/苍兰香墨 我猛地睁开眼，长吁一口气：“原来是场噩梦啊……” “哼！你这毒妇竟也来了？” 一声冷哼从身侧响起，我...
    开封第一讲书人阅读 38,196评论 0赞 269
  • 万荣杀人案实录
    序言：老挝万荣一对情侣失踪，失踪者是张志新（化名）和其女友刘颖，没想到半个月后，有当地人在树林里发现了一具尸体，经...
    沈念sama阅读 44,631评论 1赞 306
  • ?护林员之死
    正文 独居荒郊野岭守林人离奇死亡，尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,919评论 2赞 328
  • ?白月光启示录
    正文 我和宋清朗相恋三年，在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,090评论 1赞 342
  • 活死人
    序言：一个原本活蹦乱跳的男人离奇死亡，死状恐怖，灵堂内的尸体忽然破棺而出，到底是诈尸还是另有隐情，我是刑警宁泽，带...
    沈念sama阅读 34,767评论 4赞 337
  • ?日本核电站爆炸内幕
    正文 年R本政府宣布，位于F岛的核电站，受9级特大地震影响，放射性物质发生泄漏。R本人自食恶果不足惜，却给世界环境...
    茶点故事阅读 40,410评论 3赞 322
  • 男人毒药：我在死后第九天来索命
    文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹，春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,090评论 0赞 21
  • 一桩弑父案，背后竟有这般阴谋
    文/苍兰香墨 我抬头看了看天上的太阳。三九已至，却和暖如春，着一层夹袄步出监牢的瞬间，已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,328评论 1赞 267
  • 情欲美人皮
    我被黑心中介骗来泰国打工， 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留，地道东北人。 一个月前我还...
    沈念sama阅读 46,952评论 2赞 365
  • 代替公主和亲
    正文 我出身青楼，却偏偏与公主长得像，于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子，可洞房花烛夜当晚...
    茶点故事阅读 43,979评论 2赞 351

推荐阅读更多精彩内容

  • ThreadLocal用来存储线程隔离的数据。 Thread类中有一个ThreadLocalMap成员变量thre...
    Steven_SHH阅读 230评论 0赞 0
  • 前言 最近在肝原神，略微有些玩物丧志的赶脚。但鲁迅先生说过任何人都逃不过真香定律，即使他再喜欢学习也不行。----...
    小艾咪阅读 80评论 0赞 0
  • 概述 ThreadLocal可以看做是线程的局部变量，用于存储线程内部的数据的容器，其内部主要通过ThreadLo...
    jarvannnn阅读 159评论 0赞 0
  • 1、背景 在使用我们的ToolBox(我们公司的数据分析平台) 在往greenplum使用goload 入数据的...
    早点起床晒太阳阅读 112评论 0赞 0
  • 概述 ThreadLocal如果单纯从名字上来看像是“本地线程"这么个意思，只能说这个名字起的确实不太好，很容易让...
    eliter0609阅读 481评论 0赞 0