一、引言
ThreadLocal是Java帮助实现线程封闭性的典型手段。
作用：提供线程内的局部变量，这种变量在线程的生命周期内起作用，减少同一个线程内多个函数或组件之间一些公共变量的传递复杂度。同时也用来维护线程中的变量不被其他线程干扰。
这个类能使线程中的某个值与保存值的对象关联起来。ThreadLocal提供了get 与set方法，这些方法为每个使用该变量的线程都存有一份独立的副本，因此get总是返回由当前执行线程在调用set时设置的最新值。
二、ThreadLocal的简单应用
ThreadLocal是使用空间换时间，synchronized是使用时间换空间，比如在hibernate中session就存在于ThreadLocal中，避免synchronized的使用。
下面程序的输出结果为null，因为从ThreadLocal中取出的对象一定是本线程中set的对象，别的线程无法取出，因为线程自己放入的对象只能自己取得，因此无需进行加锁处理，执行效率上ThreadLocal比synchronized要高。
public class ThreadLocal_02 {
static ThreadLocal<Person> tl = new ThreadLocal<>();
public static void main(String[] args) {
new Thread(() -> {
try {
TimeUnit.SECONDS.sleep(2);
} catch (Exception e) {
e.printStackTrace();
}
System.out.println(tl.get()); // output : null
}).start();
new Thread(() -> {
try {
TimeUnit.SECONDS.sleep(1);
} catch (Exception e) {
e.printStackTrace();
}
tl.set(new Person("张三"));
}).start();
}
static class Person {
String name;
public Person(String name) {
this.name = name;
}
}
}三、对ThreadLocal的理解
ThreadLocal对象通常用于防止对可变的单例变量或全局变量进行共享。
例如，在单线程应用程序中可能会维持一个全局的数据库连接，并在程序启动时初始化这个连接对象，从而避免在调用每个方法时都要传递一个Connection对象。由于JDBC的连接对象不一定是线程安全的，因此，当多线程应用程序在没有协同的情况下使用全局变量时，就不是线程安全的。通过将JDBC的连接保存到ThreadLocal对象中，每个线程都会拥有属于自己的连接：
private static ThreadLocal<Connection> connectionHolder = new ThreadLocal<Connection>(){
public Connection initialValue() {
return DriverManager.getConnection(DB_URL);
}
};
public static Connection getConnection() {
return connectionHolder.get();
}在比如，当某个频繁执行的操作需要一个临时对象，例如一个缓冲区，而同时又希望避免在每次执行时都重新分配该临时对象，就可以使用ThreadLocal。
四、ThreadLocal的实现原理
ThreadLocal内部提供了四个对外开放的接口方法，这也是用户操作ThreadLocal对象的基本方法：
1、public T get() ：取得线程局部变量
2、public void set(T value) ：设置线程局部变量
3、public void remove() ：删除线程局部变量
4、protected T initialValue() ：返回该线程局部变量初始值
思考：ThreadLocal的实例是如何为每一个线程维护变量副本的呢？
上图来自http://www.importnew.com/22039.html
其实，每一个线程Thread其内部都维护一个ThreadLocal.ThreadLocalMap的实例对象（变量名为：threadLocals）。
你可以将这个ThreadLocalMap对象理解为一个Map，但实际上它是一个数组，一个以封装了ThreadLocal为键，Object为值的元素的数组。也就是说ThreadLocal本身不存储值，它只是作为一个key来让当前线程从ThreadLocalMap中获取value。值得注意的是，ThreadLocalMap是使用 ThreadLocal的弱引用作为 Key 的，弱引用的对象在GC时会被回收。
static class ThreadLocalMap {
//map中的每个节点Entry,其键key是ThreadLocal并且还是弱引用
static class Entry extends WeakReference<ThreadLocal<?>> {
Object value;
Entry(ThreadLocal<?> k, Object v) {
super(k);
value = v;
}
}
// 初始化容量为16，以为对其扩充也必须是2的指数
private static final int INITIAL_CAPACITY = 16;
// 真正用于存储线程的每个ThreadLocal的数组，将ThreadLocal和其对应的值包装为一个Entry
private Entry[] table;
///....其他方法和操作都和map类似
}由此，我们可以大概了解到了其线程局部变量的维护机制：为不同的线程创建不同的ThreadLocalMap，以线程本身作为区分，每个线程之间没有任何联系。
下面感兴趣可以看一下get()、set()的源码：
public T get() {
Thread t = Thread.currentThread();//当前线程
ThreadLocalMap map = getMap(t);//获取当前线程对应的ThreadLocalMap
if (map != null) {
ThreadLocalMap.Entry e = map.getEntry(this);//获取对应ThreadLocal的变量值
if (e != null) {
@SuppressWarnings("unchecked")
T result = (T)e.value;
return result;
}
}
//若当前线程还未创建ThreadLocalMap，则返回调用此方法并在其中调用createMap方法进行创建并返回初始值。
return setInitialValue();
}public void set(T value) {
Thread t = Thread.currentThread();
ThreadLocalMap map = getMap(t);
if (map != null)
map.set(this, value);
else
createMap(t, value);
}五、ThreadLocal内存泄漏问题
5.1 ThreadLocal为什么会内存泄漏？
ThreadLocalMap使用ThreadLocal的弱引用作为key，如果一个ThreadLocal没有外部强引用来引用它，那么系统 GC 的时候，这个ThreadLocal势必会被回收，这样一来，ThreadLocalMap中就会出现key为null的Entry，就没有办法访问这些key为null的Entry的value，如果当前线程再迟迟不结束（如线程池的线程回收）的话，这些key为null的Entry的value就会一直存在一条强引用链：Thread Ref -> Thread -> ThreaLocalMap -> Entry -> value 永远无法回收，造成内存泄漏。
其实，ThreadLocalMap的设计中已经考虑到这种情况，也加上了一些防护措施：在ThreadLocal的get(),set(),remove()的时候都会清除线程ThreadLocalMap里所有key为null的value。
但这些被动的预防措施并不能保证不会内存泄漏。
5.2 为什么使用弱引用？
从表面上看内存泄漏的根源在于使用了弱引用。网上的文章大多着重分析ThreadLocal使用了弱引用会导致内存泄漏，但是另一个问题也同样值得思考：为什么使用弱引用而不是强引用？
我们先来看看官方文档的说法：
To help deal with very large and long-lived usages, the hash table entries use WeakReferences for keys.
为了应对非常大和长时间的用途，哈希表使用弱引用的 key。
下面我们分两种情况讨论：
- key 使用强引用：引用的ThreadLocal的对象被回收了，但是ThreadLocalMap还持有ThreadLocal的强引用，如果没有手动删除，ThreadLocal不会被回收，导致Entry内存泄漏。
- key 使用弱引用：引用的ThreadLocal的对象被回收了，由于ThreadLocalMap持有ThreadLocal的弱引用，即使没有手动删除，ThreadLocal也会被回收。value在下一次ThreadLocalMap调用set,get，remove的时候会被清除。
比较两种情况，我们可以发现：由于ThreadLocalMap的生命周期跟Thread一样长，如果都没有手动删除对应key，都会导致内存泄漏，但是使用弱引用可以多一层保障：弱引用ThreadLocal不会内存泄漏，对应的value在下一次ThreadLocalMap调用set,get,remove的时候会被清除。
因此，ThreadLocal内存泄漏的根源是：由于ThreadLocalMap的生命周期跟Thread一样长，如果没有手动删除对应Key就会导致内存泄漏，而不是因为弱引用。
5.3 有效避免内存泄漏的最佳实践
每次使用完ThreadLocal，都调用它的remove()方法，清除数据。