Java 多线程 —— ThreadLocal

一、引言

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和其对应的值包装为一个Entryprivate Entry[] table;///....其他方法和操作都和map类似
}

由此，我们可以大概了解到了其线程局部变量的维护机制：为不同的线程创建不同的ThreadLocalMap，以线程本身作为区分，每个线程之间没有任何联系。

下面感兴趣可以看一下get()、set()的源码：

public T get() {Thread t = Thread.currentThread();//当前线程ThreadLocalMap map = getMap(t);//获取当前线程对应的ThreadLocalMapif (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);elsecreateMap(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就会导致内存泄漏，而不是因为弱引用。