ThreadLocal浅析

什么是ThreadLocal：

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

ThreadLocal一般用法介绍

首先声明，ThreadLocal只会出现在多线程编程中。单线程中完全用不到这个玩意儿。
首先我们从它的用法入手。看官方推荐我们的用法：

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 threadId =
         new ThreadLocal() {
             @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 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 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  ThreadLocal withInitial(Supplier 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 extends ThreadLocal {
        private final Supplier supplier;
        SuppliedThreadLocal(Supplier 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 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> { /** 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会被两个引用持有：

上面用户按照java推荐使用static final声明的ThreadLocal引用。

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都不会相互影响。

总结：

ThreadLocal只会用在多线程中，当前线程独立访问，推荐使用static final 修饰

Thread中持有一个ThreadLocalMap，ThreadLocalMap中持有多个的Entry。

Entry中ThreadLocal被弱引用持有，可能会被回收，ThreadLocalMap在get() set()的时候会删掉所有的已经被回收的ThreadLocal的Object，但推荐单独使用remove()删除。

取index使用了魔数0x61c88647，递加就能实现均匀，太神奇，解释不了。

ThreadLocal浅析

ThreadLocal一般用法介绍

ThreadLocal源码浅析

你可能感兴趣的:(ThreadLocal浅析)