菜鸟之路——Java并发（二）ThreadLocal
一、什么是ThreadLocal
ThreadLocal，非常多地方叫做线程本地变量，也有些地方叫做线程本地存储。事实上意思几乎相同。非常多博客都这样说：ThreadLocal为解决多线程程序的并发问题提供了一种新的思路，ThreadLocal的目的是为了解决多线程訪问资源时的共享问题。
但事实上这么说并不准确。ThreadLocal是为变量在每一个线程中都创建了一个副本（此副本的意思是通过每一个线程中的new操作来创建内容一样的新的对象，每一个线程创建一个，而不是使用对象的引用），使每一个线程能够訪问自己内部的副本变量。看看JDK中的源代码是怎么描写叙述ThreadLocal的：
This class provides thread-local variables. These variables differ from
their normal counterparts in that each thread that accesses one (via its
{@code get} or {@code set} method) has its own, independently initialized
copy of the variable. {@code ThreadLocal} instances are typically private
static fields in classes that wish to associate state with a thread (e.g.,
a user ID or Transaction ID). 意思就是：ThreadLocal类用来提供线程内部的局部变量。这样的变量在多线程环境下訪问(通过get或set方法訪问)时能保证各个线程里的变量相对独立于其它线程内的变量。ThreadLocal实例通常来说都是private static类型的，用于关联线程和线程的上下文。
即ThreadLocal的作用是提供线程内的局部变量，这样的变量在线程的生命周期内起作用。降低同一个线程内多个函数或者组件之间一些公共变量的传递的复杂度。相对于变量隔离的作用。
从字面上看起来非常easy理解，可是真正理解并非那么easy。我们还是先来看一个样例：
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();
}
}
class Dao{
public void insert() {
ConnectionManager connectionManager = new ConnectionManager();
Connection connection = connectionManager.openConnection();
//使用connection进行操作
connectionManager.closeConnection();
}
} 这样处理确实也没有不论什么问题。由于每次都是在方法内部创建的连接，那么线程之间自然不存在线程安全问题。可是这样会有一个致命的影响：导致server压力非常大。而且严重影响程序运行性能。由于在方法中须要频繁地开启和关闭数据库连接。这样不尽严重影响程序运行效率，还可能导致server压力巨大。
那么这样的情况下使用ThreadLocal是再适合只是的了，由于ThreadLocal在每一个线程中对该变量会创建一个副本，即每一个线程内部都会有一个该变量，且在线程内部不论什么地方都能够使用。线程之间互不影响，这样一来就不存在线程安全问题，也不会严重影响程序运行性能。
可是要注意。尽管ThreadLocal能够解决上面说的问题，可是由于在每一个线程中都创建了副本。所以要考虑它对资源的消耗。比方内存的占用会比不使用ThreadLocal要大。
二、ThreadLocal怎样实现
假设让大家设计ThreadLocal，大家会怎么设计？相信大部分人会有这样的想法：每一个ThreadLocal类创建一个Map，然后用线程的ID作为Map的key。实例对象作为Map的value。这样就能达到各个线程的值隔离的效果。
没错。这是最简单的设计方案。JDK最早期的ThreadLocal就是这样设计的。JDK1.3之后ThreadLocal的设计换了一种方式。
我们一起来看看眼下ThreadLocal是怎样设计的：
构造函数：ThreadLocal的构造函数签名是这样的，内部啥也没做：
/**
* Creates a thread local variable.
* @see #withInitial(java.util.function.Supplier)
*/
public 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) {
@SuppressWarnings("unchecked")
T result = (T)e.value;
return result;
}
}
return setInitialValue();
} 第一句是取得当前线程，然后通过getMap(t)方法获取到一个map。map的类型为ThreadLocalMap。然后接着以下获取到<key,value>键值对。注意这里获取键值对传进去的是 this，而不是当前线程t。
假设获取成功，则返回value值。
假设map为空。则调用setInitialValue方法返回value。
我们上面的每一句来细致分析：
首先看一下getMap方法中做了什么：
ThreadLocalMap getMap(Thread t) {
return t.threadLocals;
} 可能大家没有想到的是，在getMap中。是调用当期线程t，返回当前线程t中的一个成员变量threadLocals。
那么我们继续取Thread类中取看一下成员变量threadLocals是什么：
ThreadLocal.ThreadLocalMap threadLocals = null;实际上就是一个ThreadLocalMap，这个类型是ThreadLocal类的一个内部类。我们继续取看ThreadLocalMap的实现，get()里的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;
} 非常easy了解，就是假设map不为空，就设置键值对，为空，再创建Map，看一下createMap的实现：void createMap(Thread t, T firstValue) {
t.threadLocals = new ThreadLocalMap(this, firstValue);
} 至此，可能大部分朋友已经明确了ThreadLocal是怎样为每一个线程创建变量的副本的：首先。在每一个线程Thread内部有一个ThreadLocal.ThreadLocalMap类型的成员变量threadLocals，这个threadLocals就是用来存储实际的变量副本的。键值为当前ThreadLocal变量。value为变量副本（即T类型的变量）。
初始时，在Thread里面。threadLocals为空，当通过ThreadLocal变量调用get()方法或者set()方法，就会对Thread类中的threadLocals进行初始化。而且以当前ThreadLocal变量为键值。以ThreadLocal要保存的副本变量为value。存到threadLocals。
然后在当前线程里面。假设要使用副本变量，就能够通过get方法在threadLocals里面查找。
以下通过一个样例来证明通过ThreadLocal能达到在每一个线程中创建变量副本的效果：
public class Test {
ThreadLocal<Long> longLocal = new ThreadLocal<Long>();
ThreadLocal<String> stringLocal = new ThreadLocal<String>();
public void set() {
longLocal.set(Thread.currentThread().getId());
stringLocal.set(Thread.currentThread().getName());
}
public long getLong() {
return longLocal.get();
}
public String getString() {
return stringLocal.get();
}
public static void main(String[] args) throws InterruptedException {
final Test test = new Test();
test.set();
System.out.println(test.getLong());
System.out.println(test.getString());
Thread thread1 = new Thread(){
public void run() {
test.set();
System.out.println(test.getLong());
System.out.println(test.getString());
};
};
thread1.start();
thread1.join();
System.out.println(test.getLong());
System.out.println(test.getString());
}
} 这段代码的输出结果为：从这段代码的输出结果能够看出，在main线程中和thread1线程中，longLocal保存的副本值和stringLocal保存的副本值都不一样。
最后一次在main线程再次打印副本值是为了证明在main线程中和thread1线程中的副本值确实是不同的。
总结一下：
1）实际的通过ThreadLocal创建的副本是存储在每一个线程自己的threadLocals中的；
2）为何threadLocals的类型ThreadLocalMap的键值为ThreadLocal对象，由于每一个线程中可有多个threadLocal变量，就像上面代码中的longLocal和stringLocal；
3）在进行get之前，必须先set，否则会报空指针异常；
假设想在get之前不须要调用set就能正常訪问的话，必须重写initialValue()方法。
由于在上面的代码分析过程中，我们发现假设没有先set的话，即在map中查找不到相应的存储，则会通过调用setInitialValue方法返回i。而在setInitialValue方法中，有一个语句是T value = initialValue()， 而默认情况下。initialValue方法返回的是null。
看以下这个样例：
public class Test {
ThreadLocal<Long> longLocal = new ThreadLocal<Long>();
ThreadLocal<String> stringLocal = new ThreadLocal<String>();
public void set() {
longLocal.set(Thread.currentThread().getId());
stringLocal.set(Thread.currentThread().getName());
}
public long getLong() {
return longLocal.get();
}
public String getString() {
return stringLocal.get();
}
public static void main(String[] args) throws InterruptedException {
final Test test = new Test();
System.out.println(test.getLong());
System.out.println(test.getString());
Thread thread1 = new Thread(){
public void run() {
test.set();
System.out.println(test.getLong());
System.out.println(test.getString());
};
};
thread1.start();
thread1.join();
System.out.println(test.getLong());
System.out.println(test.getString());
}
} 在main线程中，没有先set。直接get的话。运行时会报空指针异常（这并非本身源代码抛出的异常。这个异常是由于本身的getLong方法返回是long类型。由于我们没有重写initialValue方法。默认是null，所以调用了get方法返回的是null。null强转long时抛的空指针。假设返回改为Long对象。是没问题的，但还是重写好）。
可是假设改成以下这段代码，即重写了initialValue方法：
public class Test {
ThreadLocal<Long> longLocal = new ThreadLocal<Long>(){
protected Long initialValue() {
return Thread.currentThread().getId();
};
};
ThreadLocal<String> stringLocal = new ThreadLocal<String>(){;
protected String initialValue() {
return Thread.currentThread().getName();
};
};
public void set() {
longLocal.set(Thread.currentThread().getId());
stringLocal.set(Thread.currentThread().getName());
}
public long getLong() {
return longLocal.get();
}
public String getString() {
return stringLocal.get();
}
public static void main(String[] args) throws InterruptedException {
final Test test = new Test();
test.set();
System.out.println(test.getLong());
System.out.println(test.getString());
Thread thread1 = new Thread(){
public void run() {
test.set();
System.out.println(test.getLong());
System.out.println(test.getString());
};
};
thread1.start();
thread1.join();
System.out.println(test.getLong());
System.out.println(test.getString());
}
} 就能够直接不用先set而直接调用get了。能够再总结一下ThreadLocal的设计思路：
每一个Thread维护一个ThreadLocalMap映射表。这个映射表的key是ThreadLocal实例本身，value是真正须要存储的Object。
这个方法刚好与我们開始说的简单的设计方案相反。
查阅了一下资料。这样设计的主要有以下几点优势：
1、这样设计之后每一个Map的Entry数量变小了：之前是Thread的数量，如今是ThreadLocal的数量，能提高性能，据说性能的提升不是一点两点(由于map越大基本上是走链表多，固然耗时多。)
2、当Thread销毁之后相应的ThreadLocalMap也就随之销毁了，能降低内存使用量。
三、ThreadLocal的应用场景
最常见的ThreadLocal使用场景为 用来解决 数据库连接、Session管理等。
如：
private static ThreadLocal<Connection> connectionHolder
= new ThreadLocal<Connection>() {
public Connection initialValue() {
return DriverManager.getConnection(DB_URL);
}
};
public static Connection getConnection() {
return connectionHolder.get();
} 如：
private static final ThreadLocal threadSession = new ThreadLocal();
public static Session getSession() throws InfrastructureException {
Session s = (Session) threadSession.get();
try {
if (s == null) {
s = getSessionFactory().openSession();
threadSession.set(s);
}
} catch (HibernateException ex) {
throw new InfrastructureException(ex);
}
return s;
}
四、ThreadLocal是否会引发内存泄漏
先交代一个事实：ThreadLocalMap是使用ThreadLocal的弱引用作为Key的：
static class ThreadLocalMap {
/**
* The entries in this hash map extend WeakReference, using
* its main ref field as the key (which is always a
* ThreadLocal object). Note that null keys (i.e. entry.get()
* == null) mean that the key is no longer referenced, so the
* entry can be expunged from table. Such entries are referred to
* as "stale entries" in the code that follows.
*/
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使用ThreadLocal的弱引用作为key，假设一个ThreadLocal没有外部强引用引用他，那么系统gc的时候，这个ThreadLocal势必会被回收，这样一来，ThreadLocalMap中就会出现key为null的Entry。就没有办法訪问这些key为null的Entry的value。假设当前线程再迟迟不结束的话。这些key为null的Entry的value就会一直存在一条强引用链：
Thread Ref -> Thread -> ThreaLocalMap -> Entry -> value
永远无法回收。造成内存泄露。
我们来看看究竟会不会出现这样的情况。
事实上，在JDK的ThreadLocalMap的设计中已经考虑到这样的情况，也加上了一些防护措施，以下是ThreadLocalMap的getEntry方法的源代码：
private Entry getEntry(ThreadLocal<?> key) {
int i = key.threadLocalHashCode & (table.length - 1);
Entry e = table[i];
if (e != null && e.get() == key)
return e;
else
return getEntryAfterMiss(key, i, e);
} getEntryAfterMiss函数的源代码：private Entry getEntryAfterMiss(ThreadLocal<?expungeStaleEntry函数的源代码：> key, int i, Entry e) { Entry[] tab = table; int len = tab.length; while (e != null) { ThreadLocal<?> k = e.get(); if (k == key) return e; if (k == null) expungeStaleEntry(i); else i = nextIndex(i, len); e = tab[i]; } return null; }
private int expungeStaleEntry(int staleSlot) {
Entry[] tab = table;
int len = tab.length;
// expunge entry at staleSlot
tab[staleSlot].value = null;
tab[staleSlot] = null;
size--;
// Rehash until we encounter null
Entry e;
int i;
for (i = nextIndex(staleSlot, len);
(e = tab[i]) != null;
i = nextIndex(i, len)) {
ThreadLocal<?> k = e.get();
if (k == null) {
e.value = null;
tab[i] = null;
size--;
} else {
int h = k.threadLocalHashCode & (len - 1);
if (h != i) {
tab[i] = null;
// Unlike Knuth 6.4 Algorithm R, we must scan until
// null because multiple entries could have been stale.
while (tab[h] != null)
h = nextIndex(h, len);
tab[h] = e;
}
}
}
return i;
} 整理一下ThreadLocalMap的getEntry函数的流程：1、首先从ThreadLocal的直接索引位置(通过ThreadLocal.threadLocalHashCode & (len-1)运算得到)获取Entry e。假设e不为null而且key同样则返回e；
2、假设e为null或者key不一致则向下一个位置查询，假设下一个位置的key和当前须要查询的key相等，则返回相应的Entry。否则，假设key值为null，则擦除该位置的Entry，否则继续向下一个位置查询。
在这个过程中遇到的key为null的Entry都会被擦除。那么Entry内的value也就没有强引用链。自然会被回收。细致研究代码能够发现，set操作也有相似的思想，将key为null的这些Entry都删除，防止内存泄露。
可是光这样还是不够的，上面的设计思路依赖一个前提条件：要调用ThreadLocalMap的getEntry函数或者set函数。这当然是不可能不论什么情况都成立的，所以非常多情况下须要使用者手动调用ThreadLocal的remove函数。手动删除不再须要的ThreadLocal。防止内存泄露。所以JDK建议将ThreadLocal变量定义成private static的。这样的话ThreadLocal的生命周期就更长，由于一直存在ThreadLocal的强引用，所以ThreadLocal也就不会被回收。也就能保证不论什么时候都能依据ThreadLocal的弱引用訪问到Entry的value值。然后remove它，防止内存泄露。
