共计 4436 个字符，预计需要花费 12 分钟才能阅读完成。
上一篇是分享的是《pring Boot 中 AOP 与 SpEL》，这篇分享的是《ThreadLocal 应用与原理》。
ThreadLocal 应用与原理
在解决多线程并发平安的办法中，最罕用的办法，就是应用锁，通过锁来管制多个不同线程对临界区的拜访。
然而，无论是什么样的锁，乐观锁或者乐观锁，都会在并发抵触的时候对性能产生肯定的影响。
那有没有一种办法，能够彻底防止竞争呢？
答案是必定的，这就是 ThreadLocal。
从字面意思上看，ThreadLocal 能够解释成线程的局部变量，也就是说一个 ThreadLocal 的变量只有以后本身线程能够拜访，别的线程都拜访不了，那么天然就防止了线程竞争。
因而，ThreadLocal 提供了一种不同凡响的线程平安形式，它不是在产生线程抵触时想方法解决抵触，而是彻底的防止了抵触的产生。
ThreadLocal 的根本应用
创立一个 ThreadLocal 对象：
private ThreadLocal localInt = new ThreadLocal<>();上述代码创立一个 localInt 变量，因为 ThreadLocal 是一个泛型类，这里指定了 localInt 的类型为整数。
上面展现了如果设置和获取这个变量的值：
public int setAndGet(){ localInt.set(8); return localInt.get();}上述代码设置变量的值为 8，接着获得这个值。
因为 ThreadLocal 里设置的值，只有以后线程本人看得见，这意味着你不可能通过其余线程为它初始化值。为了补救这一点，ThreadLocal 提供了一个 withInitial()办法对立初始化所有线程的 ThreadLocal 的值：
private ThreadLocal localInt = ThreadLocal.withInitial(() -> 6);上述代码将 ThreadLocal 的初始值设置为 6，这对整体线程都是可见的。
ThreadLocal 的实现原理
ThreadLocal 变量只在单个线程内可见，那它是如何做到的呢？咱们先从最根本的 get() 办法说起：
public T get() {
// 取得以后线程
Thread t = Thread.currentThread();
// 每个线程 都有一个本人的 ThreadLocalMap，//ThreadLocalMap 里就保留着所有的 ThreadLocal 变量
ThreadLocalMap map = getMap(t);
if (map != null) {
//ThreadLocalMap 的 key 就是以后 ThreadLocal 对象实例，// 多个 ThreadLocal 变量都是放在这个 map 中的
ThreadLocalMap.Entry e = map.getEntry(this);
if (e != null) {@SuppressWarnings("unchecked")
// 从 map 里取出来的值就是咱们须要的这个 ThreadLocal 变量
T result = (T)e.value;
return result;
}
}
// 如果 map 没有初始化，那么在这里初始化一下
return setInitialValue();}能够看到，所谓的 ThreadLocal 变量就是保留在每个线程的 map 中的。这个 map 就是 Thread 对象中的 threadLocals 字段。如下：
ThreadLocal.ThreadLocalMap threadLocals = null;ThreadLocal.ThreadLocalMap 是一个比拟非凡的 Map，它的每个 Entry 的 key 都是一个弱援用：
static class Entry extends WeakReference> {
/** The value associated with this ThreadLocal. */
Object value;
//key 就是一个弱援用
Entry(ThreadLocal k, Object v) {super(k);
value = v;
}
}这样设计的益处是，如果这个变量不再被其余对象应用时，能够主动回收这个 ThreadLocal 对象，防止可能的内存泄露（留神，Entry 中的 value，仍然是强援用，如何回收，见下文合成）。
了解 ThreadLocal 中的内存透露问题
尽管 ThreadLocalMap 中的 key 是弱援用，当不存在内部强援用的时候，就会主动被回收，然而 Entry 中的 value 仍然是强援用。这个 value 的援用链条如下：
能够看到，只有当 Thread 被回收时，这个 value 才有被回收的机会，否则，只有线程不退出，value 总是会存在一个强援用。然而，要求每个 Thread 都会退出，是一个极其刻薄的要求，对于线程池来说，大部分线程会始终存在在零碎的整个生命周期内，那样的话，就会造成 value 对象呈现透露的可能。解决的办法是，在 ThreadLocalMap 进行 set(),get(),remove()的时候，都会进行清理：
以 getEntry()为例：
private Entry getEntry(ThreadLocal key) {int i = key.threadLocalHashCode & (table.length - 1);
Entry e = table[i];
if (e != null && e.get() == key)
// 如果找到 key，间接返回
return e;
else
// 如果找不到，就会尝试清理，如果你总是拜访存在的 key，那么这个清理永远不会进来
return getEntryAfterMiss(key, i, e);
}上面是 getEntryAfterMiss()的实现：
private Entry getEntryAfterMiss(ThreadLocal key, int i, Entry e) {Entry[] tab = table;
int len = tab.length;
while (e != null) {
// 整个 e 是 entry，也就是一个弱援用
ThreadLocal k = e.get();
// 如果找到了，就返回
if (k == key)
return e;
if (k == null)
// 如果 key 为 null，阐明弱援用曾经被回收了
// 那么就要在这里回收外面的 value 了
expungeStaleEntry(i);
else
// 如果 key 不是要找的那个，那阐明有 hash 抵触，这里是解决抵触，找下一个 entry
i = nextIndex(i, len);
e = tab[i];
}
return null;
}真正用来回收 value 的是 expungeStaleEntry()办法，在 remove()和 set()办法中，都会间接或者间接调用到这个办法进行 value 的清理：
从这里能够看到，ThreadLocal 为了防止内存泄露，也算是花了一番大心理。不仅应用了弱援用保护 key，还会在每个操作上查看 key 是否被回收，进而再回收 value。
然而从中也能够看到，ThreadLocal 并不能 100% 保障不产生内存透露。
比方，很可怜的，你的 get()办法总是拜访固定几个始终存在的 ThreadLocal，那么清理动作就不会执行，如果你没有机会调用 set()和 remove()，那么这个内存透露仍然会产生。
因而，一个良好的习惯仍然是：当你不须要这个 ThreadLocal 变量时，被动调用 remove()，这样对整个零碎是有益处的。
ThreadLocalMap 中的 Hash 抵触解决
ThreadLocalMap 作为一个 HashMap 和 java.util.HashMap 的实现是不同的。对于 java.util.HashMap 应用的是链表法来解决抵触：
然而，对于 ThreadLocalMap，它应用的是简略的线性探测法，如果产生了元素抵触，那么就应用下一个槽位寄存：
具体来说，整个 set()的过程如下：
能够被继承的 ThreadLocal——InheritableThreadLocal
在理论开发过程中，咱们可能会遇到这么一种场景。主线程开了一个子线程，然而咱们心愿在子线程中能够拜访主线程中的 ThreadLocal 对象，也就是说有些数据须要进行父子线程间的传递。比方像这样：
public static void main(String[] args) {ThreadLocal threadLocal = new ThreadLocal();
IntStream.range(0,10).forEach(i -> {
// 每个线程的序列号，心愿在子线程中可能拿到
threadLocal.set(i);
// 这里来了一个子线程，咱们心愿能够拜访下面的 threadLocal
new Thread(() -> {System.out.println(Thread.currentThread().getName() + ":" + threadLocal.get());
}).start();
try {Thread.sleep(1000);
} catch (InterruptedException e) {e.printStackTrace();
}
});
}执行上述代码，你会看到：
Thread-0:null
Thread-1:null
Thread-2:null
Thread-3:null因为在子线程中，是没有 threadLocal 的。如果咱们心愿子线能够看到父线程的 ThreadLocal，那么就能够应用 InheritableThreadLocal。顾名思义，这就是一个反对线程间父子继承的 ThreadLocal，将上述代码中的 threadLocal 应用 InheritableThreadLocal：
InheritableThreadLocal threadLocal = new InheritableThreadLocal();再执行，就能看到：
Thread-0:0
Thread-1:1
Thread-2:2
Thread-3:3
Thread-4:4能够看到，每个线程都能够拜访到从父过程传递过去的一个数据。尽管 InheritableThreadLocal 看起来挺不便的，然而仍然要留神以下几点：
变量的传递是产生在线程创立的时候，如果不是新建线程，而是用了线程池里的线程，就不灵了
变量的赋值就是从主线程的 map 复制到子线程，它们的 value 是同一个对象，如果这个对象自身不是线程平安的，那么就会有线程平安问题
写在最初的话
明天，咱们介绍了 ThreadLocal，ThreadLocal 在 Java 的多线程开发中有着非常重要的作用。
在这里，咱们介绍了 ThreadLocal 的根本应用和实现原理，尤其重点介绍了基于以后实现原理下可能存在的内存透露问题。
最初，还介绍了一个用于在父子线程间传递数据的非凡的 ThreadLocal 实现，心愿对大家有所帮忙。
- 以上就是《《ThreadLocal 应用与原理》的分享。
- 也欢送大家交换探讨，该文章若有不正确的中央，心愿大家多多包涵。
- 你们的反对就是我最大的能源，如果对大家有帮忙给个赞哦~~~
