ThreadLocal是什么？
ThreadLocal是java语言实现的一种线程本地存储的方式,有时候我们会遇到这样一种需求:每条线程都要去存取一个同名的变量,但是每条线程中该变量的值都是不一样的,那么如果让我们去实现的话,会采用什么方式去实现呢? 也许你会认为你可以去使用一个线程共享的Map<Thread,Object>, 其中Map中的key为线程对象而value则是我们需要存储的值,然后通过map.get(Thread.currentThread())来获取本线程中该变量的值.
如果不考虑同步和效率的问题的话,这种实现方式是完全可以的,但是,问题的关键在于,如果有很多线程进行操作这个Map呢?为了保证线程的安全性,势必要对Map进行加锁,每当有一个线程在操作这个map时,其他线程只能去等待锁资源的释放,这种性能是我们不能够容忍的。
也许你会反驳说我们可以使用java.util.concurrenct.*包下面的ConcurrencyHashMap来提高并发率,但是它只是降低了锁的粒度,并没有从根本上避免同步锁,而jdk提供的ThreadLocal则很好的解决了这个问题。
我们首先先来看一下ThreadLocal的简单用法
//为不同的线程关联不同的用户ID
public class ThreadLocalDemo {
private static volatile ThreadLocal<String> userID = new ThreadLocal<>();
public static void main(String[] args) {
Runnable r = new Runnable() {
@Override
public void run() {
String name = Thread.currentThread().getName();
if (name.equals("A")){
userID.set("aaaaaaa");
}else if (name.equals("B")){
userID.set("bbbbbbb");
}
System.out.println("ThreadName:"+name+" userID: "+userID.get());
}
};
Thread t1 = new Thread(r);
Thread t2 = new Thread(r);
t1.setName("A");
t2.setName("B");
t1.start();
t2.start();
}
}
输出结果
ThreadName:A userID: aaaaaaa
ThreadName:B userID: bbbbbbb
从这个例子中我们可以看出,虽然说是共享了同一个ThreadLocal,但是对于每一个线程来说,它们可以存储自己的值,不同线程存储的内容互不相干。
看完了ThreadLocal的简单用法之后,让我们再去探索一下ThreadLocal的使用原理
我使用的是jdk1.8,通过分析源码我们可以发现,不同线程和本地存储的变量值的映射关系是由一个称之为ThreadLoaclMap的类来实现的,从名字中我们可以看出,它是一个Map,对于Map来说,就应该有键值对,现在我们已经知道值是我们存储的变量值了,那么键是什么呢？这可能跟我们最初的想法不一样,它的键并不是我们原以为的Thread对象,而是一个ThreadLocal。那你可能会产生疑问,那它又是怎样实现Thread和value的关联的呢？
在这里它采用的方式是由Thread类来管理ThreadLocalMap对象.
打开Thread.class我们可以看到, Thread类持有一个ThreadLocalMap
从类型的定义来看,我们可以看出ThreadLocalMap是ThreadLocal的内部类,那么这个内部类又是怎么定义的呢?让我们进入ThreadLocal的源码实现去看一下
static class ThreadLocalMap {
static class Entry extends WeakReference<ThreadLocal<?>> {
/** The value associated with this ThreadLocal. */
Object value;
Entry(ThreadLocal<?> k, Object v) {
super(k);
value = v;
}
}
private Entry[] table;
//.......省略以下代码
}
从这里我们可以看出来,ThreadLocalMap是由一个Entry数组table构成的,也就是说,是由一个一个的Entry构成的,我们还可以发现,Entry继承了 WeakReference<ThreadLocal<?>,在构造Entry的时候也调用了super(k),这里为什么会牵扯到弱引用呢?这跟使用ThreadLocal可能会造成的内存泄露的风险有关系,如果key是弱引用,当没有指向key的强引用后,在进行垃圾回收时,就会把这个key回收掉,至于具体的原因,我们会到后面进行分析。
大体结构我们应该清楚了,也就是说,ThreadLocalMap实际存储本地值,ThreadLocalMap是ThreadLocal的一个静态内部类,ThreadLocal实例的set(),get()等方法是对ThreadLocalMap的实际操作来设置线程本地存储的值和获取该值,而ThreadLocalMap又是由Thread来管理的。。。到了这里你如果没有被绕晕,那么恭喜你到目前为止的内容你大概都理解了,如果被绕晕的话,也没关系,我们还有下面这一张图。
这样一来,Thread,ThreadLocalMap,ThreadLocal这三者的关系我们已经清楚了,那么ThreadLocal是怎样具体实现对本地存储值的set()和get()呢？
继续从源码开始探究。。
public void set(T value) {
//当执行set方法的时候,首先会获取当前线程的对象
Thread t = Thread.currentThread();
//根据线程对象获取指定线程里面持有的ThreadLocalMap
ThreadLocalMap map = getMap(t);
//如果我们获取到了map,这个map存在不为空
if (map != null)
//对map进行set操作,key为调用该set方法的ThreadLocal对象,值为我们需要存储的值
map.set(this, value);
else
//如果map为空,则调用createMap()来创建一个
createMap(t, value);
}
public T get() {
//首先获得当前线程
Thread t = Thread.currentThread();
//根据线程对象获取指定线程里面持有的ThreadLocalMap
ThreadLocalMap map = getMap(t);
//如果我们获取到了map,这个map存在不为空
if (map != null) {
//以调用该方法的ThreadLocal对象,也就是this为key,获取Entry
ThreadLocalMap.Entry e = map.getEntry(this);
//如果获取的Entry不为空
if (e != null) {
@SuppressWarnings("unchecked")
//获取Entry的value值返回
T result = (T)e.value;
return result;
}
}
//如果为空,调用setInitialValue()并返回
return setInitialValue()并返回
}
//根据线程对象获取指定线程里面持有的ThreadLocalMap
ThreadLocalMap getMap(Thread t) {
return t.threadLocals;
}
由于每一条线程均含有各自私有的ThreadLocalMap容器，这些容器相互独立互不影响，因此不会存在线程安全性问题，从而也无需使用同步机制来保证多条线程访问容器的互斥性。
关注一下ThreadLocal内存泄露的问题
在ThreadLocalMap中，只有key是弱引用，value仍然是一个强引用。当某一条线程中的ThreadLocal使用完毕，没有强引用指向它的时候，这个key指向的对象就会被垃圾收集器回收，从而这个key就变成了null；然而，此时value和value指向的对象之间仍然是强引用关系，只要这种关系不解除，value指向的对象永远不会被垃圾收集器回收，从而导致内存泄漏！
不过不用担心，ThreadLocal提供了这个问题的解决方案。
每次操作set、get、remove操作时，ThreadLocal都会将key为null的Entry删除，从而避免内存泄漏。
那么问题又来了，如果一个线程运行周期较长，而且将一个大对象放入LocalThreadMap后便不再调用set、get、remove方法，此时该仍然可能会导致内存泄漏。
这个问题确实存在，没办法通过ThreadLocal解决，而是需要程序员在完成ThreadLocal的使用后要养成手动调用remove的习惯，从而避免内存泄漏。
ThreadLocal的 应用场景
1.Web系统Session的存储就是ThreadLocal一个典型的应用场景。
Web容器采用线程隔离的多线程模型，也就是每一个请求都会对应一条线程，线程之间相互隔离，没有共享数据。这样能够简化编程模型，程序员可以用单线程的思维开发这种多线程应用。
当请求到来时，可以将当前Session信息存储在ThreadLocal中，在请求处理过程中可以随时使用Session信息，每个请求之间的Session信息互不影响。当请求处理完成后通过remove方法将当前Session信息清除即可。
2.Spring的事务管理器通过AOP切入业务代码，在进入业务代码前，会根据对应的事务管理器提取出相应的事务对象,为了获得同一个Connection,Spring在这里也巧妙利用了ThreadLocal的特性
假如事务管理器是DataSourceTransactionManager，就会从DataSource中获取一个连接对象，通过一定的包装后将其保存在ThreadLocal中。并且Spring也将DataSource进行了包装，重写了其中的getConnection()方法，或者说该方法的返回将由Spring来控制，这样Spring就能让线程内多次获取到的Connection对象是同一个。
为什么要放在ThreadLocal里面呢？因为Spring在AOP后并不能向应用程序传递参数，应用程序的每个业务代码是事先定义好的，Spring并不会要求在业务代码的入口参数中必须编写Connection的入口参数。此时Spring选择了ThreadLocal，通过它保证连接对象始终在线程内部，任何时候都能拿到，此时Spring非常清楚什么时候回收这个连接，也就是非常清楚什么时候从ThreadLocal中删除这个元素
该篇博客是我的一些总结,很多内容是参考了大闲人柴毛毛的博客总结,加上我的一些个人总结,为了尊重原作,
我附上了他的博客地址https://juejin.im/post/5aa74967f265da23a334e373
作者:lhsjohn
