前言

图解形式来通关 ThreadLocal，同时心愿你们有肯定的JVM 根底，这样食用起来会更香。

置信大伙对 ThreadLocal 并不生疏，工作中罕用，同时也是面试高频题，然而大部分人对 ThreadLocal 的了解可能只是「线程的本地变量，Map 构造」，看完本文让大伙真正了解 ThreadLocal，给大伙工作带来帮忙，也让面试有更多的谈资。

内容纲要

Java 对象援用级别

在聊 ThreadLocal 前，先做前置常识铺垫，谈谈 Java 对象援用级别。

为了使程序能更灵便地管制对象生命周期，从 JDK1.2 版本开始，JDK 把对象的援用级别由高到低分为强援用、软援用、弱援用、虚援用四种级别。

强援用 StrongReference

强援用是咱们最常见的对象，它属于不可回收资源，垃圾回收器（前面简称 G C）相对不会回收它，即便是内存不足，J V M 宁愿抛出 OutOfMemoryErrorM 异样，使程序终止，也不会来回收强援用对象。

软援用 SoftReference

如果对象是软援用，那它的性质属于可有可无，因为内存空间短缺的状况下，G C 不会回收它，然而内存空间缓和，G C 发现它仅有软援用，就会回收该对象，所以软援用对象适宜作为内存敏感的缓存对象。

只有对象仅被 SoftReference 援用，它才是软援用级别对象，因为对象能够在多处被援用，所以 SoftReference 援用的对象，它可能在其余处被强援用了。

弱援用 WeakReference

弱援用对象绝对软援用对象具备更短暂的生命周期，只有 G C 发现它仅有弱援用，不论内存空间是否短缺，都会回收它，不过 G C 是一个优先级很低的线程，因而不肯定会很快发现那些仅有弱援用的对象。

只有对象仅被 WeakReference 援用，它才是弱援用级别对象，因为对象能够在多处被援用，所以 WeakReference 援用的对象，它可能在其余处被强援用了。

虚援用 PhantomReference

顾名思义，虚援用形同虚设，与其余几种援用不同，虚援用不会决定对象的生命周期。

如果一个对象仅有虚援用，那它就和没有任何援用一样，任何时候都可能被 G C 回收。

读到这里会不会感觉虚援用和弱援用没区别？它们的区别如下

• SoftReference、WeakReference 援用的对象没被回收时，能够应用 get 办法获取实在对象地址
• PhantomReference 应用 get 办法永远返回 null

简略说就是「无奈通过虚援用来获取对象的实在地址」

小结

Java 中 SoftReference、WeakReference、PhantomReference，能够了解为对象援用级别包装类，在我的项目中应用对应的包装类，赋予对象援用级别。

虚援用图中，呈现了 ReferenceQueue（援用队列），援用队列是配合对象援用级别包装类（SoftReference、WeakReference、PhantomReference）应用，当对象援用级别包装类所指向的对象，被垃圾回收后，该对象援用级别包装类被追加到援用队列，因而能够通过援用队列做 G C 相干统计或额定数据清理等操作。

ThreadLocal

ThreadLocal 很多中央叫线程本地变量，也有些中央叫线程本地存储，其实意思差不多。ThreadLocal 为变量在每个线程中都创立了一个正本，每个线程能够拜访本人外部的正本变量。

ThreadLocal 是什么

Thread 类申明了成员变量 threadLocals，threadLocals 才是真正的线程本地变量，因而每个 Thread 都有本人的线程本地变量，所以线程本地变量领有线程隔离个性，也就是天生的线程平安。

从上图能够看到 threadLocals 成员变量类是 ThreadLocal.ThreadLocalMap，即是 ThreadLocal 提供的外部类，因而 Thread 线程本地变量的创立、新增、获取、删除实现外围，必然是围绕 threadLocals，所以开发者也是围绕 threadLocals 实现性能，为了后续重复使用，还会对代码实现进行封装复用，而 ThreadLocal 就是线程本地变量工具类，由 J D K 提供，线程本地变量的性能都曾经实现好了，开箱即用，造福宽广开发人员。

ThreadLocal 罕用的办法

• set：为以后线程设置变量，以后 ThreadLocal 作为索引
• get：获取以后线程变量，以后 ThreadLocal 作为索引
• initialValue（钩子办法须要子类实现）：赖加载模式初始化线程本地变量，执行 get 时，发现线程本地变量为 null，就会执行 initialValue 的内容
• remove：清空以后线程的 ThreadLocal 索引与映射的元素

一个 Threa 能够领有多个 ThreadLocal 键值对（存储在 ThreadLocalMap 构造），又因为 ThreadLocalMap 依赖以后 Thread，Thread 销毁时 ThreadLocalMap 也会随之销毁，所以 ThreadLocalMap 的生命周期与 Thread 绑定。

当初总结出「本地线程变量的作用域，属于以后线程整个范畴，一个线程能够逾越多个办法应用本地线程变量」，当你心愿某些变量在某 Thread 的多个办法中共享 并保障线程平安，那就大胆的应用 ThreadLocal（ps：肯定要想分明，是某个变量被 Thread 生命周期内多个办法共享，还是多个 Thread 共享这个变量！）。

ThreadLocal 源码

先来看看 User 类实现的线程本地变量代码

办法也不多，别离是 initialValue、get、set、remove，接下来这些办法源码进行解析。

ThreadLocalMap 构造

为了前面的源码解析体验更好，有必要介绍下 ThreadLocalMap，顾名思义，它是 Map 构造，然而本文次要内容不是 Map，所以上一图，疾速过一下这块内容。

通过上图，置信大伙对 ThreadLocalMap 构造曾经十分清晰，不知有没有仔细的小伙伴发现 ThreadLocal 竟被弱援用持有？

为什么 ThreadLocal 会被弱援用？这块纳闷前面会给大伙安顿的明明白白，最初上一张 ThreadLocalMap 源码图。

get 获取变量

步骤如下

1. 获取以后线程
2. 获取以后线程的本地变量
3. 线程本地变量没有被创立，执行 setInitialValue 办法进行初始化，并返回 value 值
4. 线程本地变量存在，ThreadLocal 计算成索引从 本地线程变量 获取 Entry，如果 Entry 为 null，执行 setInitialValue 办法进行初始化，并返回 value 值，否则通过 Entry 获取 value 返回

initialValue 办法

步骤如下

1. 通过 get 办法触发
2. 执行初始化，获取到 value
3. 获取以后线程
4. 获取以后线程本地变量
5. 如果以后线程本地变量存在，ThreadLocal 计算成索引设置映射的 value，否则创立线程本地变量再做后续的设置操作
6. 返回 value 值

set 设置变量

步骤如下

1. 获取以后线程
2. 获取线程本地变量
3. 本地变量不为空，以后 ThreadLocal 为索引设置映射的 value，否则创立线程本地变量再做后续的设置操作

remove 革除变量

步骤如下

1. 获取 Entry 数组
2. 以后 ThreadLocal 计算出索引
3. 依据索引获取 Entry 元素（若是第一次没有命中，就循环直到 null）
4. 革除 Entry 元素

小结

源码非常简略，外围就三样 ThreadLocal 线程本地变量工具类（同时作为索引）、Entry 根本元素（由弱援用包装类 ThreadLocal 与 value 组成），Entry 数组容器，到这里流程很清晰了，ThreadLocal 计算出数组索引，用 ThreadLocal 与 value 构建出 Entry 元素，最终放入 Entry 容器中，置信大伙都能写进去。

为何采纳弱援用

为什么 Entry 中对 ThreadLocal 应用弱援用？反诘一句，如果应用强援用，会产生什么事件？

上图的代码作用仅仅只是是为了让大伙去了解为什么应用弱援用，个别开发中不会呈现这样的代码（真呈现了，这程序员怕是要拉去祭天）。

回到正题，咱们疾速对代码进行解析，首先 ThreadContextTest 持有公有的动态变量 ThreadLocal，且 ThreadContextTest 禁止实例化，接着执行静态方法 run 触发动态块为 ThreadLocal 设置 User 变量 并打消 ThreadLocal 强援用，此时以后线程的本地变量领有了 Entry 元素。

问题来了，要如何获取到 Entry 元素，按失常流程，ThreadLocal 执行 get 办法，get 会应用以后 ThreadLocal 计算出索引，最终获取到 Entry 元素，可是当初的问题如同下图。

咱们不晓得 key 是什么，如何去获取映射的 value，同样的情理，都没有入口去获取到 ThreadContextTest.ThreadLoca，天然没方法获取映射的 Entry 元素。

设计中采纳 Map 构造存储数据，却不能通过 key 去获取 value，这设计显著不合理，又因 key、value 值是强援用，导致 G C 无奈回收，造成内存溢出。

所以针对这种不合理的设计场景 J D K 做了优化，对 Entry 中的 ThreadLocal 应用弱援用，当 G C 发现它仅有弱援用的时候，会进行回收。

remove 背地的意义

还没完结，下面留了个小尾巴，大伙都晓得 Entry 中对 ThreadLocal 应用弱援用，但 value 是强援用，如果呈现下面提到的不合理场景，value 值无奈清理，最终内存溢出。

其实 value 作为强援用设计属于正当，如果用软或弱援用，就出大问题了，程序跑着跑着忽然 get 到了一个 null，预计都得骂娘了，所以为解决内存溢出问题 J D K 提供 remove 办法，使开发人员能够抉择手动清理整个 Entry 元素，避免内存溢出。

还记的之前说过吗？线程本地变量的生命周期与线程绑定，个别线程的生命周期比拟短，线程完结时，线程本地变量天然就销毁了，软援用与 remove 会不会有点多余了？

业务瞬息万变，大部分状况来说线程的生命周期比拟短，但也业务场景会导致线程的生命周期较长，甚至可能线程有限循环执行，这些是你没方法预料到的，数量一旦上来很容易内存溢出，所以集体倡议应用完之后及时清理 ThreadLocal，理由如下

• 生命周期较长的线程场景
• 有限循环线程的场景
• 线程池场景（因为线程池能够复用线程，而且公司应用的框架可能会定制化线程池，你不能保障他会在线程池内帮你 remove）

唠叨唠叨

先祝大伙新年快乐，万事如意！！！博主两周肝一篇，尽管周期有点长，然而品质有保障，码文不易，如果感觉本文对您有帮忙，欢送分享给你的敌人，也给阿星点个「点赞 + 珍藏」，这对阿星十分重要，谢谢您们，给各位小姐姐小哥哥们抱拳了，咱们下次见！

对于我

公众号 :「程序猿阿星」专一技术原理、源码，通过图解形式输入技术，这里将会分享操作系统、计算机网络、Java、分布式、数据库等精品原创文章，期待你的关注。