java基础（十）之深入剖析ThreadLocal

ThreadLocal在日常开发中使用并不是很频繁，但是在很多开源框架中都能见到这种用法。今天我们就来深入剖析下ThreadLocal原理以及ThreadLocal的应用场景。本文从以下几个方面来剖析ThreadLocal原理。
　　一.ThreadLocal引例
　　二.深入剖析ThreadLocal
　　三.ThreadLocal与线程同步机制比较
　　四.ThreadLocal内存泄露问题(京东面试题)

一.ThreadLocal引例
ThreadLocal，很多地方叫做线程本地变量，也有些地方叫做线程本地存储，其实意思差不多。可能很多朋友都知道ThreadLocal为变量在每个线程中都创建了一个副本，那么每个线程可以访问自己内部的副本变量。
我们还是先来看一个例子：

class ConnectionManager {    private static Connection connect = null;    public static Connection openConnection() {        if(connect == null){            connect = DriverManager.getConnection();        }        return connect;    }    public static void closeConnection() {        if(connect!=null)            connect.close();    }}

假设有这样一个数据库链接管理类，这段代码在单线程中使用是没有任何问题的，但是如果在多线程中使用呢？很显然，在多线程中使用会存在线程安全问题：第一，这里面的2个方法都没有进行同步，很可能在openConnection方法中会多次创建connect；第二，由于connect是共享变量，那么必然在调用connect的地方需要使用到同步来保障线程安全，因为很可能一个线程在使用connect进行数据库操作，而另外一个线程调用closeConnection关闭链接。

　　所以出于线程安全的考虑，必须将这段代码的两个方法进行同步处理，并且在调用connect的地方需要进行同步处理。

　　这样将会大大影响程序执行效率，因为一个线程在使用connect进行数据库操作的时候，其他线程只有等待。

　　那么大家来仔细分析一下这个问题，这地方到底需不需要将connect变量进行共享？事实上，是不需要的。假如每个线程中都有一个connect变量，各个线程之间对connect变量的访问实际上是没有依赖关系的，即一个线程不需要关心其他线程是否对这个connect进行了修改的。

　　到这里，可能会有朋友想到，既然不需要在线程之间共享这个变量，可以直接这样处理，在每个需要使用数据库连接的方法中具体使用时才创建数据库链接，然后在方法调用完毕再释放这个连接。比如下面这样：

class ConnectionManager {    private  Connection connect = null;    public Connection openConnection() {        if(connect == null){            connect = DriverManager.getConnection();        }        return connect;    }    public void closeConnection() {        if(connect!=null)            connect.close();    }} //操作Connectionclass Dao{    public void insert() {        ConnectionManager connectionManager = new ConnectionManager();        Connection connection = connectionManager.openConnection();        //使用connection进行操作        connectionManager.closeConnection();    }}

这样处理确实也没有任何问题，由于每次都是在方法内部创建的连接，那么线程之间自然不存在线程安全问题。但是这样会有一个致命的影响：导致服务器压力非常大，并且严重影响程序执行性能。由于在方法中需要频繁地开启和关闭数据库连接，这样不尽严重影响程序执行效率，还可能导致服务器压力巨大。
　　那么这种情况下使用ThreadLocal是再适合不过的了，因为ThreadLocal在每个线程中对该变量会创建一个副本，即每个线程内部都会有一个该变量，且在线程内部任何地方都可以使用，线程之间互不影响，这样一来就不存在线程安全问题，也不会严重影响程序执行性能。
　　但是要注意，虽然ThreadLocal能够解决上面说的问题，但是由于在每个线程中都创建了副本，所以要考虑它对资源的消耗，比如内存的占用会比不使用ThreadLocal要大。
　　还有一种解决方法是创建资源管理池,不过需要用到线程同步的知识,可以极大的缓解资源的使用。ThreadLocal这种方法在并发不是很大时可以使用,但是大并发下为每个线程分配一个链接,这样明显是太耗费资源了。关于如何通过资源池来管理可以看我前面关于线程同步的文章

二.深入剖析ThreadLocal

1.简易版ThreadLocal

在ThreadLocal类中有一个Map，用于存储每一个线程的变量的副本。比如下面的示例实现：

public class SimpleThreadLocal {//存放各线程下变量副本private Map valueMap = Collections.synchronizedMap(new HashMap());//键为线程对象，值为本线程的变量副本public void set(Object newValue) {valueMap.put(Thread.currentThread(), newValue);}public Object get() {valueMap.put(currentThread, o);}return o;}//移除该线程下变量值public void remove() {valueMap.remove(Thread.currentThread());}//变量值初始化public Object initialValue() {return null;}}

虽然上述ThreadLocal实现版本显得比较幼稚，但它和JDK所提供的ThreadLocal类在实现思路上是相近的。

2.jdk版 ThreadLocal
在上面谈到了对ThreadLocal的一些理解，那我们下面来看一下具体ThreadLocal是如何实现的。

　　先了解一下ThreadLocal类提供的几个方法：

public T get() { }public void set(T value) { }public void remove() { }protected T initialValue() { }

get()方法是用来获取ThreadLocal在当前线程中保存的变量副本，set()用来设置当前线程中变量的副本，remove()用来移除当前线程中变量的副本，initialValue()是一个protected方法，一般是用来在使用时进行重写的，它是一个延迟加载方法，下面会详细说明。

　　首先我们来看一下ThreadLocal类是如何为每个线程创建一个变量的副本的。
　　先看下get方法的实现：

　　    public T get() {        Thread t = Thread.currentThread();        ThreadLocalMap map = getMap(t);        if (map != null) {            ThreadLocalMap.Entry e = map.getEntry(this);            if (e != null)                return (T)e.value;        }        return setInitialValue();    }

第一句是取得当前线程，然后通过getMap(t)方法获取到一个map，map的类型为ThreadLocalMap。然后接着下面获取到

    ThreadLocalMap getMap(Thread t) {        return t.threadLocals;    }

可能大家没有想到的是，在getMap中，是调用当期线程t，返回当前线程
t中的一个成员变量threadLocals。

那么我们继续取Thread类中取看一下成员变量threadLocals是什么：

　    ThreadLocal.ThreadLocalMap threadLocals = null;

实际上就是一个ThreadLocalMap，这个类型是ThreadLocal类的一个内部类，我们继续取看ThreadLocalMap的实现：

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;            }        }

可以看到ThreadLocalMap的Entry继承了WeakReference，并且使用ThreadLocal作为键值。

然后再继续看set方法的具体实现：

    public void set(T value) {        Thread t = Thread.currentThread();        //获得当前线程中存储的threadlocals变量        ThreadLocalMap map = getMap(t);        if (map != null)            map.set(this, value);        else        //为当前线程中threadlocals变量赋值            createMap(t, value);    }

这里其实就是将线程的局部变量放入线程绑定的threadlocals中,可以从
createMap()中明显看出。

    void createMap(Thread t, T firstValue) {    //线程中绑定的threadlocals变量        t.threadLocals = new ThreadLocalMap(this, firstValue);    }

再继续看setInitialValue方法的具体实现：

  private T setInitialValue() {        T value = initialValue();        Thread t = Thread.currentThread();        ThreadLocalMap map = getMap(t);        if (map != null)            map.set(this, value);        else            createMap(t, value);        return value;    }

这里重点在于initialValue()方法,其他与set()方法一致。

    protected T initialValue() {        return null;    }

这里默认初始值为null,所以一般需要我们重写该方法。

至此，可能大部分朋友已经明白了ThreadLocal是如何为每个线程创建变量的副本的：
　　首先，在每个线程Thread内部有一个hreadLocal.ThreadLocalMap类型的成员变量threadLocals，这个threadLocals就是用来存储实际的变量副本的，键值为当前ThreadLocal变量，value为变量副本（即T类型的变量）。
　　初始时，在Thread里面，threadLocals为空，当通过ThreadLocal变量调用get()方法或者set()方法，就会对Thread类中的threadLocals进行初始化，并且以当前ThreadLocal变量为键值，以ThreadLocal要保存的副本变量为value，存到threadLocals。
　　然后在当前线程里面，如果要使用副本变量，就可以通过get方法在threadLocals里面查找。

　　总结一下：
　　1）实际的通过ThreadLocal创建的副本是存储在每个线程自己的threadLocals中的；
　　2）为何threadLocals的类型ThreadLocalMap的键值为ThreadLocal对象，因为每个线程中可有多个threadLocal变量。
　　
　　3）在进行get之前，必须先set，否则会报空指针异常；如果想在get之前不需要调用set就能正常访问的话，必须重写initialValue()方法。

三.ThreadLocal与线程同步机制比较

1.ThreadLocal和线程同步机制相比有什么优势呢？

ThreadLocal和线程同步机制都是为了解决多线程中相同变量的访问冲突问题。

在同步机制中，通过对象的锁机制保证同一时间只有一个线程访问变量。这时该变量是多个线程共享的，使用同步机制要求程序慎密地分析什么时候对变量进行读写，什么时候需要锁定某个对象，什么时候释放对象锁等繁杂的问题，程序设计和编写难度相对较大。

而ThreadLocal则从另一个角度来解决多线程的并发访问。在编写多线程代码时，可以把不安全的变量封装进ThreadLocal。
由于ThreadLocal中可以持有任何类型的对象，低版本JDK所提供的get()返回的是Object对象，需要强制类型转换。但JDK 5.0通过泛型很好的解决了这个问题，在一定程度地简化ThreadLocal的使用，代码清单 9 2就使用了JDK 5.0新的ThreadLocal版本。

概括起来说，对于多线程资源共享的问题，同步机制采用了“以时间换空间”的方式，而ThreadLocal采用了“以空间换时间”的方式。前者仅提供一份变量，让不同的线程排队访问，而后者为每一个线程都提供了一份变量，因此可以同时访问而互不影响。

2.ThreadLocal应用场景

Spring使用ThreadLocal解决线程安全问题
我们知道在一般情况下，TransactionSynchronizationManager、LocaleContextHolder等）中非线程安全状态采用ThreadLocal进行处理，让它们也成为线程安全的状态，因为有状态的Bean就可以在多线程中共享了。
一般的Web应用划分为展现层、服务层和持久层三个层次，在不同的层中编写对应的逻辑，下层通过接口向上层开放功能调用。在一般情况下，从接收请求到返回响应所经过的所有程序调用都同属于一个线程，如图9‑2所示：图1同一线程贯通三层
这样你就可以根据需要，将一些非线程安全的变量以ThreadLocal存放，在同一次请求响应的调用线程中，所有关联的对象引用到的都是同一个变量。

下面的实例能够体现Spring对有状态Bean的改造思路：

TopicDao：非线程安全

public class TopicDao {private Connection conn;         ①一个非线程安全的变量public void addTopic(){Statement stat = conn.createStatement();     ②引用非线程安全变量…}}

由于①处的conn是成员变量，因为addTopic()方法是非线程安全的，必须在使用时创建一个新TopicDao实例（非singleton）。因为需要每次重新建立连接,所以非singleton会导致浪费大量链接。

下面使用ThreadLocal对conn这个非线程安全的“状态”进行改造：

TopicDao：线程安全

import java.sql.Connection;import java.sql.Statement;public class TopicDao {①使用ThreadLocal保存Connection变量private static ThreadLocal<Connection> connThreadLocal = new ThreadLocal<Connection>();public static Connection getConnection(){②如果connThreadLocal没有本线程对应的Connection创建一个新的Connection，并将其保存到线程本地变量中。return connThreadLocal;}public void addTopic() {④从ThreadLocal中获取线程对应的ConnectionStatement stat = getConnection().createStatement();}}

不同的线程在使用TopicDao时，这样，就保证了不同的线程使用线程相关的Connection，而不会使用其它线程的Connection。因此，这个TopicDao就可以做到singleton共享了。

当然，这个例子本身很粗糙，将Connection的ThreadLocal直接放在DAO只能做到本DAO的多个方法共享Connection时不发生线程安全问题，但无法和其它DAO共用同一个Connection，要做到同一事务多DAO共享同一Connection，必须在一个共同的外部类使用ThreadLocal保存Connection。

总结一下:
ThreadLocal是解决线程安全问题一个很好的思路，它通过为每个线程提供一个独立的变量副本解决了变量并发访问的冲突问题。在很多情况下，ThreadLocal比直接使用synchronized同步机制解决线程安全问题更简单，更方便，且结果程序拥有更高的并发性。

四.ThreadLocal内存泄露问题

在上面提到过，每个thread中都存在一个map, map的类型是ThreadLocal.ThreadLocalMap. Map中的key为一个threadlocal实例. 这个Map的确使用了弱引用,不过弱引用只是针对key. 每个key都弱引用指向threadlocal. 当把threadlocal实例置为null以后,没有任何强引用指向threadlocal实例,所以threadlocal将会被gc回收. 但是,我们的value却不能回收,因为存在一条从current thread连接过来的强引用. 只有当前thread结束以后, current thread就不会存在栈中,强引用断开, Current Thread, Map, value将全部被GC回收.
　　所以得出一个结论就是只要这个线程对象被gc回收，就不会出现内存泄露，但在threadLocal设为null和线程结束这段时间不会被回收的，就发生了我们认为的内存泄露。其实这是一个对概念理解的不一致，也没什么好争论的。最要命的是线程对象不被回收的情况，这就发生了真正意义上的内存泄露。比如使用线程池的时候，线程结束是不会销毁的，会再次使用的。就可能出现内存泄露。

参考:

本文是在认真研读博客文章http://www.cnblogs.com/dolphin0520/的基础上,进行部分补充。