内容导航
- 什么是ThreadLocal
- ThreadLocal的使用
- 分析ThreadLocal的实现原理
- ThreadLocal的应用场景及问题
一、什么是ThreadLocal
ThreadLocal，简单翻译过来就是本地线程，但是直接这么翻译很难理解ThreadLocal的作用，如果换一种说法，可以称为线程本地存储。简单来说，就是ThreadLocal为共享变量在每个线程中都创建一个副本，每个线程可以访问自己内部的副本变量。这样做的好处是可以保证共享变量在多线程环境下访问的线程安全性
二、ThreadLocal的使用演示
ThreadLocal的使用
没有使用ThreadLocal时
通过一个简单的例子来演示一下ThreadLocal的作用，这段代码是定义了一个静态的成员变量 num，然后通过构造5个线程对这个 num做递增
运行结果
每个线程都会对这个成员变量做递增，如果线程的执行顺序不确定，那么意味着每个线程获得的结果也是不一样的。
使用了ThreadLocal以后
通过ThreadLocal对上面的代码做一个改动
运行结果
从结果可以看到，每个线程的值都是5，意味着各个线程都是从ThreadLocal的 initialValue方法中拿到默认值0并且做了 num+=5的操作，同时也意味着每个线程从ThreadLocal中拿到的值都是0，这样使得各个线程对于共享变量num来说，是完全隔离彼此不相互影响.
ThreadLocal会给定一个初始值，也就是 initialValue()方法，而每个线程都会从ThreadLocal中获得这个初始化的值的副本，这样可以使得每个线程都拥有一个副本拷贝
三、从源码分析ThreadLocal的实现
看到这里，估计有很多人都会和我一样有一些疑问
- 每个线程的变量副本是怎么存储的?
- ThreadLocal是如何实现多线程场景下的共享变量副本隔离?
带着疑问，来看一下ThreadLocal这个类的定义(默认情况下,JDK的源码都是基于1.8版本)
从ThreadLocal的方法定义来看,还是挺简单的。就几个方法
- get: 获取ThreadLocal中当前线程对应的线程局部变量
- set：设置当前线程的线程局部变量的值
- remove：将当前线程局部变量的值删除
另外，还有一个initialValue()方法，在前面的代码中有演示，作用是返回当前线程局部变量的初始值，这个方法是一个 protected方法，主要是在构造ThreadLocal时用于设置默认的初始值
set方法的实现
set方法是设置一个线程的局部变量的值，相当于当前线程通过set设置的局部变量的值，只对当前线程可见。
- Thread.currentThread 获取当前执行的线程
- getMap(t) ,根据当前线程得到当前线程的ThreadLocalMap对象，这个对象具体是做什么的?稍后分析
- 如果map不为空，说明当前线程已经构造过ThreadLocalMap，直接将值存储到map中
- 如果map为空，说明是第一次使用，调用 createMap构造
ThreadLocalMap是什么?
我们来分析一下这句话， ThreadLocalMapmap=getMap(t)获得一个ThreadLocalMap对象，那这个对象是干嘛的呢?
其实不用分析，基本上也能猜测出来，Map是一个集合，集合用来存储数据，那么在ThreadLocal中，应该就是用来存储线程的局部变量的。 ThreadLocalMap这个类很关键。
t.threadLocals实际上就是访问Thread类中的ThreadLocalMap这个成员变量
从上面的代码发现每一个线程都有自己单独的ThreadLocalMap实例，而对应这个线程的所有本地变量都会保存到这个map内
ThreadLocalMap是在哪里构造?
在 set方法中，有一行代码 createmap(t,value);，这个方法就是用来构造ThreadLocalMap，从传入的参数来看，它的实现逻辑基本也能猜出出几分吧
Threadt 是通过 Thread.currentThread()来获取的表示当前线程，然后直接通过 newThreadLocalMap将当前线程中的 threadLocals做了初始化
ThreadLocalMap是一个静态内部类，内部定义了一个Entry对象用来真正存储数据
分析到这里，基本知道了ThreadLocalMap长啥样了，也知道它是如何构造的?那么我看到这里的时候仍然有疑问
- Entry集成了 WeakReference,这个表示什么意思?
- 在构造ThreadLocalMap的时候 newThreadLocalMap(this,firstValue);,key其实是this，this表示当前对象的引用，在当前的案例中，this指的是 ThreadLocal<Integer>local。那么多个线程对应同一个ThreadLocal实例，怎么对每一个ThreadLocal对象做区分呢？
解惑WeakReference
weakReference表示弱引用，在Java中有四种引用类型，强引用、弱引用、软引用、虚引用。
使用弱引用的对象，不会阻止它所指向的对象被垃圾回收器回收。
在Java语言中, 当一个对象o被创建时, 它被放在Heap里. 当GC运行的时候, 如果发现没有任何引用指向o, o就会被回收以腾出内存空间. 也就是说, 一个对象被回收, 必须满足两个条件:
- 没有任何引用指向它
- GC被运行.
这段代码中，构造了两个对象a,b，a是对象DemoA的引用，b是对象DemoB的引用，对象DemoB同时还依赖对象DemoA，那么这个时候我们认为从对象DemoB是可以到达对象DemoA的。这种称为强可达(strongly reachable)
如果我们增加一行代码来将a对象的引用设置为null，当一个对象不再被其他对象引用的时候，是会被GC回收的，但是对于这个场景来说，即时是a=null，也不可能被回收，因为DemoB依赖DemoA，这个时候是可能造成内存泄漏的
通过弱引用，有两个方法可以避免这样的问题
对于方法2来说，DemoA只是被弱引用依赖，假设垃圾收集器在某个时间点决定一个对象是弱可达的(weakly reachable)（也就是说当前指向它的全都是弱引用），这时垃圾收集器会清除所有指向该对象的弱引用，然后把这个弱可达对象标记为可终结(finalizable)的，这样它随后就会被回收。
试想一下如果这里没有使用弱引用，意味着ThreadLocal的生命周期和线程是强绑定，只要线程没有销毁，那么ThreadLocal一直无法回收。而使用弱引用以后，当ThreadLocal被回收时，由于Entry的key是弱引用，不会影响ThreadLocal的回收防止内存泄漏，同时，在后续的源码分析中会看到，ThreadLocalMap本身的垃圾清理会用到这一个好处，方便对无效的Entry进行回收
解惑ThreadLocalMap以this作为key
在构造ThreadLocalMap时，使用this作为key来存储，那么对于同一个ThreadLocal对象，如果同一个Thread中存储了多个值，是如何来区分存储的呢？
答案就在 firstKey.threadLocalHashCode&(INITIAL_CAPACITY-1)
关键点是 threadLocalHashCode，它相当于一个ThreadLocal的ID，实现的逻辑如下
这里用到了一个非常完美的散列算法，可以简单理解为，对于同一个ThreadLocal下的多个线程来说，当任意线程调用set方法存入一个数据到Entry中的时候，其实会根据 threadLocalHashCode生成一个唯一的id标识对应这个数据，存储在Entry数据下标中。
- threadLocalHashCode是通过
- nextHashCode.getAndAdd(HASH_INCREMENT)来实现的
- i*HASH_INCREMENT+HASH_INCREMENT,每次新增一个元素(ThreadLocal)到Entry[],都会自增0x61c88647,目的为了让哈希码能均匀的分布在2的N次方的数组里
- Entry[i]= hashCode & (length-1)
魔数0x61c88647
从上面的分析可以看出，它是在上一个被构造出的ThreadLocal的threadLocalHashCode的基础上加上一个魔数0x61c88647。我们来做一个实验，看看这个散列算法的运算结果
输出结果
根据运行结果，这个算法在长度为2的N次方的数组上，确实可以完美散列，没有任何冲突, 是不是很神奇。
魔数0x61c88647的选取和斐波那契散列有关，0x61c88647对应的十进制为1640531527。而斐波那契散列的乘数可以用 (long)((1L<<31)(Math.sqrt(5)-1)); 如果把这个值给转为带符号的int，则会得到-1640531527。也就是说(long)((1L<<31)(Math.sqrt(5)-1));得到的结果就是1640531527，也就是魔数0x61c88647
总结，我们用0x61c88647作为魔数累加为每个ThreadLocal分配各自的ID也就是threadLocalHashCode再与2的幂取模，得到的结果分布很均匀。
图形分析
为了更直观的体现 set方法的实现，通过一个图形表示如下
set剩余源码分析
前面分析了set方法第一次初始化ThreadLocalMap的过程，也对ThreadLocalMap的结构有了一个全面的了解。那么接下来看一下map不为空时的执行逻辑
主要逻辑
- 根据key的散列哈希计算Entry的数组下标
- 通过线性探索探测从i开始往后一直遍历到数组的最后一个Entry
- 如果map中的key和传入的key相等，表示该数据已经存在，直接覆盖
- 如果map中的key为空，则用新的key、value覆盖，并清理key=null的数据
- rehash扩容
replaceStaleEntry
由于Entry的key为弱引用，如果key为空，说明ThreadLocal这个对象被GC回收了。 replaceStaleEntry的作用就是把陈旧的Entry进行替换
cleanSomeSlots
这个函数有两处地方会被调用，用于清理无效的Entry
- 插入的时候可能会被调用
- 替换无效slot的时候可能会被调用
区别是前者传入的n为元素个数，后者为table的容量
expungeStaleEntry
执行一次全量清理
get操作
set的逻辑分析完成以后，get的源码分析就很简单了
setInitialValue
根据 initialValue()的value初始化ThreadLocalMap
- 从当前线程中获取ThreadLocalMap，查询当前ThreadLocal变量实例对应的Entry，如果不为null,获取value,返回
- 如果map为null,即还没有初始化，走初始化方法
remove方法
remove的方法比较简单，从Entry[]中删除指定的key就行
四、ThreadLocal的应用场景及问题
应用场景
ThreadLocal的实际应用场景：
- 比如在线程级别，维护session,维护用户登录信息userID（登陆时插入，多个地方获取）
- 数据库的链接对象 Connection，可以通过ThreadLocal来做隔离避免线程安全问题
问题
ThreadLocal的内存泄漏
ThreadLocalMap中Entry的key使用的是ThreadLocal的弱引用，如果一个ThreadLocal没有外部强引用，当系统执行GC时，这个ThreadLocal势必会被回收，这样一来，ThreadLocalMap中就会出现一个key为null的Entry，而这个key=null的Entry是无法访问的，当这个线程一直没有结束的话，那么就会存在一条强引用链
Thread Ref - > Thread -> ThreadLocalMap - > Entry -> value 永远无法回收而造成内存泄漏
其实我们从源码分析可以看到，ThreadLocalMap是做了防护措施的
- 首先从ThreadLocal的直接索引位置(通过
- ThreadLocal.threadLocalHashCode & (len-1)运算得到)获取Entry e，如果e不为null并且key相同则返回e
- 如果e为null或者key不一致则向下一个位置查询，如果下一个位置的key和当前需要查询的key相等，则返回对应的Entry，否则，如果key值为null，则擦除该位置的Entry，否则继续向下一个位置查询
在这个过程中遇到的key为null的Entry都会被擦除，那么Entry内的value也就没有强引用链，自然会被回收。仔细研究代码可以发现，set操作也有类似的思想，将key为null的这些Entry都删除，防止内存泄露。
但是这个设计一来与一个前提条件，就是调用get或者set方法，但是不是所有场景都会满足这个场景的，所以为了避免这类的问题，我们可以在合适的位置手动调用ThreadLocal的remove函数删除不需要的ThreadLocal，防止出现内存泄漏
所以建议的使用方法是
- 将ThreadLocal变量定义成private static的，这样的话ThreadLocal的生命周期就更长，由于一直存在ThreadLocal的强引用，所以ThreadLocal也就不会被回收，也就能保证任何时候都能根据ThreadLocal的弱引用访问到Entry的value值，然后remove它，防止内存泄露
- 每次使用完ThreadLocal，都调用它的remove()方法，清除数据。
推荐一个交流学习交流圈子：142019080 里面会分享一些资深架构师录制的视频录像：有Spring，MyBatis，Netty源码分析，高并发、高性能、分布式、微服务架构的原理，JVM性能优化这些成为架构师必备的知识体系。还能领取免费的学习资源，目前受益良多
