一、故事
地铁上，小帅无力地倚靠着杆子，脑子里尽是刚才面试官的夺命连环问，“用过TheadLocal么？ThreadLocal是如何解决共享变量访问的安全性的呢？你觉得啥场景下会用到TheadLocal? 我们在日常用ThreadLocal的时候需要注意什么？ThreadLocal在高并发场景下会造成内存泄漏吗？为什么？如何避免？......”
这些问题，如同阴影一般，在小帅的脑海里挥之不去。
是的，他万万没想到，自诩“多线程小能手”的他栽在了ThreadLocal上。
这是小帅苦投了半个月简历之后才拿到的面试机会，然而又丧失了。当下行情实在是卷到了极点。
都两个月了，面试机会少，居然还每次都被问翻，这样下去真要回老家另谋出路了，小帅内心五味成杂......
小伙伴们，试问一下，如果是你，面对上述的问题，你能否对答如流呢？
二、概要
既然被问到了，那么作为事后诸葛的老猫就和大家一起来接面试官的招吧。
我们将从以下点来全面剖析一下ThreadLocal。
概览
三、基本篇
1.什么是ThreadLocal？
ThreadLocal英文翻译过来就是：线程本地量，它其实是一种线程的隔离机制，保障了多线程环境下对于共享变量访问的安全性。
看到上面的定义之后，那么问题就来了，ThreadLocal是如何解决共享变量访问的安全性的呢？
其实ThreadLocal为变量在每个线程中都创建了一个副本，那么每个线程可以访问自己内部的副本变量。由于副本都归属于各自的线程，所以就不存在多线程共享的问题了。
便于理解，我们看一下下图。
结构图
至于上述图中提及的threadLocals(ThreadLocalMap)，我们后文看源代码的时候再继续来看。大家心中暂时有个概念。
既然都是保证线程访问的安全性，那么和Synchronized区别是什么呢？
在上面聊到共享变量访问安全性的问题上，其实大家还会很容易想起另外一个关键字Synchronized。聊聊区别吧，整理了一张图，看起来可能会更加直观一些，如下。
对比
通过上图，我们发现ThreadLocal其实是一种线程隔离机制。Synchronized则是一种基于Happens-Before规则里的监视器锁规则从而保证同一个时刻只有一个线程能够对共享变量进行更新。
Synchronized加锁会带来性能上的下降。ThreadLocal采用了空间换时间的设计思想，也就是说每个线程里面都有一个专门的容器来存储共享变量的副本信息，然后每个线程只对自己的变量副本做相对应的更新操作，这样避免了多线程锁竞争的开销。
2.ThreadLocal的使用
上面说了这么多，咱们来使用一下。就拿SimpleDateFormat来做个例子。当然也会有一道这样的面试题，SimpleDateFormat是否是线程安全的？在阿里Java开发规约中，有强制性地提到SimpleDateFormat 是线程不安全的类。其实主要的原因是由于多线程操作SimpleDateFormat中的Calendar对象引用，然后出现脏读导致的。
踩坑代码：
/**
* @author 公众号：程序员老猫
* @date 2024/2/1 22:58
*/
public class DateFormatTest {
private static final SimpleDateFormat simpleDateFormat =
new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
public static Date parse(String dateString) {
Date date = null;
try {
date = simpleDateFormat.parse(dateString);
} catch (ParseException e) {
e.printStackTrace();
}
return date;
}
public static void main(String[] args) {
ExecutorService executorService = Executors.newFixedThreadPool(20);
for (int i = 0; i {
System.out.println(parse("2024-02-01 23:34:30"));
});
}
executorService.shutdown();
}
}上述咱们通过线程池的方式针对SimpleDateFormat进行了测试。其输出结果如下。
我们可以看到刚开始好好的，后面就异常了。
我们通过ThreadLocal的方式将其优化一下。代码如下：
/**
* @author 公众号：程序员老猫
* @date 2024/2/1 22:58
*/
public class DateFormatTest {
private static final ThreadLocal dateFormatThreadLocal =
ThreadLocal.withInitial(() -> new SimpleDateFormat("yyyy-MM-dd HH:mm:ss"));
public static Date parse(String dateString) {
Date date = null;
try {
date = dateFormatThreadLocal.get().parse(dateString);
} catch (ParseException e) {
e.printStackTrace();
}
return date;
}
public static void main(String[] args) {
ExecutorService executorService = Executors.newFixedThreadPool(10);
for (int i = 0; i {
System.out.println(parse("2024-02-01 23:34:30"));
});
}
executorService.shutdown();
}
}运行了一下,完全正常了。
Thu Feb 01 23:34:30 CST 2024
Thu Feb 01 23:34:30 CST 2024
Thu Feb 01 23:34:30 CST 2024
Thu Feb 01 23:34:30 CST 2024
Thu Feb 01 23:34:30 CST 2024
Thu Feb 01 23:34:30 CST 2024
Thu Feb 01 23:34:30 CST 2024
Thu Feb 01 23:34:30 CST 2024
Thu Feb 01 23:34:30 CST 20243.TheadLocal使用场景
那么我们什么时候会用到ThreadLocal呢？
上面针对SimpleDateFormat的封装也算是一个吧。
- 用来替代参数链传递：在编写API接口时，可以将需要传递的参数放入ThreadLocal中，从而不需要在每个调用的方法上都显式地传递这些参数。这种方法虽然不如将参数封装为对象传递来得常见，但在某些情况下可以简化代码结构。
- 数据库连接和会话管理：在某些应用中，如Web应用程序，ThreadLocal可以用来保持对数据库连接或会话的管理，以简化并发控制并提高性能。例如，可以使用ThreadLocal来维护一个连接池，使得每个请求都能共享相同的连接，而不是每次都需要重新建立连接。
- 全局存储信息：例如在前后端分离的应用中，ThreadLocal可以用来在服务端维护用户的上下文信息或者一些配置信息，而不需要通过HTTP请求携带大量的用户信息。这样做可以在不改变原有架构的情况下，提供更好的用户体验。
如果大家还能想到其他使用的场景也欢迎留言。
四、升华篇
1.ThreadLocal原理
上述其实咱们聊得相对而言还是比较浅的。那么接下来，咱们丰富一下之前提到的结构图，从源代码侧深度剖一下ThreadLocal吧。
深度结构图
对应上述图中，解释一下。
- 图中有两个线程Thread1以及Thread2。
- Thread类中有一个叫做threadLocals的成员变量，它是ThreadLocal.ThreadLocalMap类型的。
- ThreadLocalMap内部维护了Entry数组，每个Entry代表一个完整的对象，key是ThreadLocal本身，value是ThreadLocal的泛型对象值。
对应的我们看一下Thread的源代码，如下：
public class Thread implements Runnable {
...
ThreadLocal.ThreadLocalMap threadLocals = null;
...
}在源码中threadLocals的初始值为Null。
抽丝剥茧，咱们继续看一下ThreadLocalMap在调用构造函数进行初始化的源代码：
static class ThreadLocalMap {
private static final int INITIAL_CAPACITY = 16; //初始化容量
private Entry[] table; //ThreadLocalMap数据真正存储在table中
private int size = 0; //ThreadLocalMap条数
private int threshold; // 默认为0,达到这个大小，则扩容
//类Entry的实现
static class Entry extends WeakReference> {
Object value;
Entry(ThreadLocal k, Object v) {
super(k);
value = v;
}
}
...
}上文中其实我们已经知道Entry中以key和value的形式存储，key是ThreadLocal本身，上面代码中我们看到entry进行key设置的时候用的是super(k)。那就意味着调用的父类的方法去设置了key，我们再看一下父类是什么，父类其实是WeakReference。关于WeakReference底层的实现，大家有兴趣可以展开去看看源代码，老猫在这里直接说结果。
WeakReference 如字面意思，弱引用，当一个对象仅仅被weak reference（弱引用）指向, 而没有任何其他strong reference（强引用）指向的时候, 如果这时GC运行, 那么这个对象就会被回收，不论当前的内存空间是否足够，这个对象都会被回收。
关于这些引用的强弱，稍微聊一下，这里其实涉及到jvm的回收机制。在JDK1.2之后，java对引用的概念其实做了扩充的，分为强引用，软引用，弱引用，虚引用。
- 强引用：其实就是咱们一般用“=”的赋值行为，如 Student s = new Student(),只要强引用还在，对象就不会被回收。
- 软引用：不是必须存活的对象，jvm在内存不够的情况下即将内存溢出前会对其进行回收。例如缓存。
- 弱引用：非必须存活的对象，引用关系比软引用还弱，无论内存够还是不够，下次的GC一定会被回收。
- 虚引用：别名幽灵引用或者幻影引用。等同于没有引用，唯一的目的是对象被回收的时候会受到系统通知。
明白这些概念之后，咱们再看看上面的源代码，我们就会发现，原来Key其实是弱引用，而里面的value因为是直接赋值行为所以是强引用。
如下图：
jvm存储
图中我们可以看到由于threadLocal对象是弱引用，如果外部没有强引用指向的话，它就会被GC回收，那么这个时候导致Entry的key就为NULL，如果此时value外部也没有强引用指向的话，那么这个value就永远无法访问了，按道理也该被回收。但是由于entry还在强引用value（看源代码）。那么此时value就无法被回收，此时内存泄漏就出现了。本质原因是因为value成为了一个永远无法被访问也无法被回收的对象。
那肯定有小伙伴会有疑问了，线程本身生命周期不是很短么，如果短时间内被销毁，就不会内存泄漏了，因为只要线程销毁，那么value也会被回收。这话是没错。但是咱们的线程是计算机珍贵资源，为了避免重复创建线程带来开销，系统中我们往往会使用线程池（线程池传送门）,如果使用线程池的话，那么线程的生命周期就被拉长了，那么就可想而知了。
(2) 如何避免
解法如下：
- 每次使用完毕之后记得调用一下remove()方法清除数据。
- ThreadLocal变量尽量定义成static final类型，避免频繁创建ThreadLocal实例。这样可以保证程序中一直存在ThreadLocal强引用，也能保证任何时候都能通过ThreadLocal的弱引用访问Entry的value值，从而进行清除。
不过话说回来，其实ThreadLocal内部也做了优化的。在set()的时候也会采样清理，扩容的时候也会检查（这里希望大家自己深入看一下源代码），在get（）的时候，如果没有直接命中或者向后环形查找的时候也会进行清理。但是为了系统的稳健万无一失，所以大家尽量还是将上面的两个注意点在写代码的时候注意下。
总结
面试的时候大家总会去背一些八股文，但是这种也只是临时应付面试官而已，真正的懂其中的原理才是硬道理。无论咋问，万变不离核心原理。当然这些核心原理在我们的日常编码中也会给我们带来很大的帮助，用法很简单，翻车了如何处理，那还不是得知其所以然么，伙伴们，你们觉得呢？
