什么是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<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()，看到一幅图画的很好，能标明介绍到的一些目标之间的引证联系图，实线表示强引证，虚线表示弱引证：
- 上面用户依照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中持有多个<ThreadLocal,Object>的Entry。
- Entry中ThreadLocal被弱引证持有，或许会被收回，ThreadLocalMap在get() set()的时分会删掉一切的现已被收回的ThreadLocal的Object，但引荐独自运用remove()删去。
- 取index运用了魔数0x61c88647，递加就能完成均匀，太奇特，解说不了。
