不论是Atomic还是synchronized或者Lock，其实都是采用同步的方式（串行或者自旋等）解决了线程安全问题。这里我们将介绍另外一种解决线程安全问题的思路----副本的方式。
如果你有一个全局共享的变量，那么多线程并发的时候，对这个共享变量的访问是不安全的。方法内的局部变量是线程安全的，由于每个线程都会有自己的副本。也就是说局部变量被封闭在线程内部，其它线程无法访问（引用型有所区别）。那么有没有作用域介于两者之间，既能保证线程安全，又不至于只局限于方法内部的方式呢？答案是肯定的，我们使用ThreadLocal就可以做到这一点。ThreadLocal变量的作用域是为线程，也就是说线程内跨方法共享。例如某个对象的方法A对threadLocal变量赋值，在同一个线程中的另外一个对象的方法B能够读取到该值。因为作用域为同一个线程，那么自然就是线程安全的。但是需要注意的是，如果threadLocal存储的是共享变量的引用，那么同样会有线程安全问题。
1、ThreadLocal 的使用场景
ThreadLocal的特性决定了它的使用场景。由于ThreadLocal中存储的变量是线程隔离的，所以一般在以下情况使用ThreadLocal：
1、存储需要在线程隔离的数据。比如线程执行的上下文信息，每个线程是不同的，但是对于同一个线程来说会共享同一份数据。Spring MVC的 RequestContextHolder 的实现就是使用了ThreadLocal；
2、跨层传递参数。层次划分在软件设计中十分常见。层次划分后，体现在代码层面就是每层负责不同职责，一个完整的业务操作，会由一系列不同层的类的方法调用串起来完成。有些时候第一层获得的一个变量值可能在第三层、甚至更深层的方法中才会被使用。如果我们不借助ThreadLocal，就只能一层层地通过方法参数进行传递。使用ThreadLocal后，在第一层把变量值保存到ThreadLocal中，在使用的层次方法中直接从ThreadLocal中取出，而不用作为参数在不同方法中传来传去。不过千万不要滥用ThreadLocal，它的本意并不是用来跨方法共享变量的。结合第一种情况，我们放入ThreadLocal跨层传递的变量一般也是具有上下文属性的。比如用户的信息等。这样我们在AOP处理异常或者其他操作时可以很方便地获取当前登录用户的信息。
2、如何使用 ThreadLocal
ThreadLocal使用起来非常简单，我们先看一个简单的例子。
可以看到每个线程为同一个ThreadLocal对象set不同的值，但各个线程打印出来的依旧是自己保存进去的值，并没有被其它线程所覆盖。
一般来说，在实践中，我们会把ThreadLocal对象声名为static final，作为私有变量封装到自定义的类中。另外提供static的set和get方法。如下面的代码：
public final class OperationInfoRecorder {
private static final ThreadLocal<OperationInfoDTO> THREAD_LOCAL = new ThreadLocal<>();
private OperationInfoRecorder() {
}
public static OperationInfoDTO get() {
return THREAD_LOCAL.get();
}
public static void set(OperationInfoDTO operationInfoDTO) {
THREAD_LOCAL.set(operationInfoDTO);
}
public static void remove() {
THREAD_LOCAL.remove();
}
}
这样做的目的有二:
- 1、static 确保全局只有一个保存OperationInfoDTO对象的ThreadLocal实例；
- 2、final 确保ThreadLocal的实例不可更改。防止被意外改变，导致放入的值和取出来的不一致。另外还能防止ThreadLocal的内存泄漏，具体原因下文中会有讲解。
使用的时候可以在任何方法的任何位置调用OperationInfoRecorder的set或者get方法，保存和取出。如下面代码：
OperationInfoRecorder.set(operationInfoDTO)
OperationInfoRecorder.get()
3、ThreadLocal源代码解析
学习到这里，你一定很好奇ThreadLocal是如何做到多个线程对同一个对象set操作，但只会get出自己set进去的值呢？这个现象有点违背我们的认知。接下来我们就从set方法入手，来看看ThreadLocal的源代码：
public void set(T value) {
Thread t = Thread.currentThread();
ThreadLocalMap map = getMap(t);
if (map != null)
map.set(this, value);
else
createMap(t, value);
}
一眼看过去，一下就可以看到map。没错，如果ThreadLocal能够保存多个线程的变量值，那么它一定是借助容器来实现的。
这个map不是一般的map，可以看到它是通过当前线程对象获取到的ThreadLocalMap。看到这里应该看出些端倪，这个map其实是和Thread绑定的。接下来我们看getMap方法的代码：
ThreadLocalMap getMap(Thread t) {
return t.threadLocals;
}
原来这个ThreadLocal就存方法Thread对象上。下面我们看看Thread中的相关代码：
/* ThreadLocal values pertaining to this thread. This map is maintained
* by the ThreadLocal class. */
ThreadLocal.ThreadLocalMap threadLocals = null;
注释中写的很清楚，这个属性由ThreadLocal来维护。threadLocals的访问控制决定在包外是无法直接访问的。所以我们在使用的时候只能通过ThreadLocal对象来访问。
set时，会把当前threadLocal对象作为key，你想要保存的对象作为value，存入map。
看到这里，我们大至已经理清了ThreadLocal和Thread的关系，我们看下图：
我们接下来分析get方法，代码如下：
public T get() {
Thread t = Thread.currentThread();
ThreadLocalMap map = getMap(t);
if (map != null) {
ThreadLocalMap.Entry e = map.getEntry(this);
if (e != null) {
@SuppressWarnings("unchecked")
T result = (T)e.value;
return result;
}
}
return setInitialValue();
}
get方法也是先取得当前线程对象中保存的ThreadLocalMap对象，然后使用当前threadLocal对象从map中取得相应的value。
每个Thread的ThreadMap以threadLocal作为key，保存自己线程的value副本。我们可以这么来理解ThreadLocal，其实ThreadLocal对象是你要真正保存对象的身份代表。而这个身份在每个线程中对应的值，其实是保存在每个线程中，并没有保存在ThreadLocal对象中。
这里可以举个例子，学校里要每班评选一名学习标兵，一名道德标兵。班主任会进行评选然后记录下来。学生标兵及道德标兵的身份就是两个ThreadLocal对象，而每个班主任是一个线程，记录的评选结果的小本子就是ThreadLocalMap对象。每个班主任会在自己的小本子上记录下评选结果，比如说一班班主任记录：道德标兵：小明，学习标兵：小红。二班班主任记录：道德标兵：小赵，学习标兵：小岩。通过这个例子大家应该很清楚ThreadLocal的原理了。
ThreadLocal的设计真的非常巧妙，看似自己保存了每个线程的变量副本，其实每个线程的变量副本是保存在线程对象中，那么自然就线程隔离了。如此分析起来，是不是有一种ThreadLocal没做什么事情，却抢了头功的感觉？其实不然。Thread对象中用来保存变量副本的ThreadLocalMap的定义就在ThreadLocal中。我们接下来分析ThreadLocalMap的源代码。
4、ThreadLocalMap分析
ThreadLocalMap是ThreadLocal的静态内部类。ThreadLocalMap的功能其实是和HashMap类似的，但是为什么不直接使用HashMap呢？在ThreadLocalMap中使用WeakReference包装后的ThreadLocal对象作为key，也就是说这里对ThreadLocal对象为弱引用。当ThreadLocal对象在ThreadLocalMap引用之外，再无其他引用的时候能够被垃圾回收。如下面代码所示：
static class Entry extends WeakReference<ThreadLocal<?>> {
/** The value associated with this ThreadLocal. */
Object value;
Entry(ThreadLocal<?> k, Object v) {
super(k);
value = v;
}
}
这样做会带来新的问题。如果ThreadLocal对象被回收，那么ThreadLocalMap中保存的key值就变成了null，而value会一直被Entry引用，而Entry又被threadLocalMap对象引用，threadLocalMap对象又被Thread对象所引用，那么当Thread一直不终结的话，value对象就会一直驻留在内存中，直至Thread被销毁后，才会被回收。这就是ThreadLocal引起内存泄漏问题。
如上图所示，由于ThreadLocal对象是弱引用，如果外部没有强引用指向它，它就会被GC回收，导致Entry的Key为null
由于ThreadLocal对象是弱引用，如果外部没有强引用指向它，它就会被GC回收，导致Entry的Key为null
如果当前的情况下在栈中将threadlocal1的引用设置为null，强引用1将会失效，那堆中的threadlocal1对象因为ThreadLocalMap的key对它的引用是弱引用，将会在下一次gc被回收，那就会出现key变成null，如果这时value外部也没有强引用指向它，那么value就永远也访问不到了，按理也应该被GC回收，但是由于ThreadLocalMap.Entry对象还在强引用value，导致value无法被回收，这时「内存泄漏」就发生了，value成了一个永远也无法被访问，但是又无法被回收的对象。
而ThreadLocalMap在设计的时候也考虑到这一点，在get和set的时候，会把遇到的key为null的entry清理掉。不过这样做是依赖于我们后面对ThreadLocal的持续使用也不能100%保证能够清理干净，如果我们在秒杀服务中使用，有可能造成内存的瞬间打满。
通常，我们可以通过以下两种方式来避免这个问题：
- 1、把ThreadLocal对象声明为static，这样
ThreadLocal成为了类变量，生命周期不是和对象绑定，而是和类绑定，延长了声明周期，避免了被回收； - 2、在使用完ThreadLocal变量后，手动remove掉，防止ThreadLocalMap中Entry一直保持对value的强引用。导致value不能被回收。
- 3、减少损害，尽量不要在ThreadLocal中放大对象
4、总结
通过本节学习，我们掌握了ThreadLocal 的原理和其使用场景。绝大多数情况下，ThreadLocal用于存储和线程相关的上下文信息，也就是线程共享的信息，便于同一线程的不同方法中取值，而不用作为方法参数层层传递。
使用的时候需要注意几个常见的问题1.内存泄漏 2.上下文丢失（常见于线程池，并行流）3.数据交互污染（常见于线程池）
网友评论