前言
ThreadLocal是什么？有什么作用？我们直接说结论。
- ThreadLocal跟线程同步机制没有半毛钱关系。
- ThreadLocal提供了解决多线程环境下成员变量问题的解决方案，但是并不是用共享变量的方式。
例子1
public class Main {
public static void main(String[] args) {
// write your code here
Count count = new Count();
for (int i = 0 ; i < 3 ; i++){
new CountThread(count).start();
}
}
}
class Count{
private static ThreadLocal count = new ThreadLocal(){
@Override
protected Integer initialValue() {
return 0;
}
};
public void addCount(){
count.set(count.get()+1);
}
public void printCount(){
System.out.println(Thread.currentThread().getName()+"-"+count.get());
}
}
class CountThread extends Thread{
private Count count;
public CountThread(Count count){
this.count = count;
}
@Override
public void run() {
for (int i = 0 ;i < 5 ; i++){
count.addCount();
count.printCount();
}
}
}
这个例子中，Count类是计数器类，CountThread是执行计数的线程，用来模拟多线程情况下的计数效果。下面就是输出结果。
Thread-0-1
Thread-0-2
Thread-0-3
Thread-0-4
Thread-0-5
Thread-1-1
Thread-1-2
Thread-1-3
Thread-2-1
Thread-2-2
Thread-2-3
Thread-2-4
Thread-2-5
Thread-1-4
Thread-1-5
很明显，运行结果是符合我们预期的效果。从结果上看，线程间对变量的访问操作做到了隔离，每个计数线程都启到了计数的功能，并不相互影响。那么如果把整型换成引用类型呢？工作线程访问变量也能起到隔离的作用吗？那我们就再写个例子验证下。
例子2
public static void main(String[] args) {
Ref ref = new Ref();
for (int i = 0 ; i < 2 ; i++){
new RefThread(ref).start();
}
}
class A{}
class Ref{
private static A a = new A();
private static ThreadLocal ref = new ThreadLocal(){
@Override
protected A initialValue() {
return a;
}
};
public void change(){
ref.set(new A());
}
public void printAddress(){
System.out.println(Thread.currentThread().getName()+"-"+ref.get());
}
}
class RefThread extends Thread{
private Ref ref;
public RefThread(Ref ref){
this.ref = ref;
}
@Override
public void run() {
for (int i = 0 ; i < 2 ; i++) {
ref.printAddress();
ref.change();
ref.printAddress();
}
}
}
例子2和例子1大同小异，区别在于变量类型变成了引用类型，通过打印内存地址来判断在线程内变量使用的连续性，和多线程环境下的变量隔离性。我们看下输出结果。
Thread-0-com.loubinfeng.A@c1e719b
Thread-0-com.loubinfeng.A@2d99e68
Thread-0-com.loubinfeng.A@2d99e68
Thread-0-com.loubinfeng.A@6e61aeb
Thread-1-com.loubinfeng.A@c1e719b
Thread-1-com.loubinfeng.A@189e7143
Thread-1-com.loubinfeng.A@189e7143
Thread-1-com.loubinfeng.A@16598c20
从结果上看很明显，同个线程变量初始是指向统一内存地址，后续变化是连续的，多线程环境下变量也是隔离的。也就是不同是引用类型还是基础数据类型，使用ThreadLocal都能解决多线程环境的变量问题。
例子3
从例子2中，我们发现两个线程变量副本初始都指向同一内存地址，所以我们改例子2，如下：
class A{
int p;
public A add(){
p++;
return this;
}
}
class Ref{
private static A a = new A();
private static ThreadLocal ref = new ThreadLocal(){
@Override
protected A initialValue() {
return a;
}
};
public void change(){
ref.set(ref.get().add());
}
public void printAddress(){
System.out.println(Thread.currentThread().getName()+"-"+ref.get()+"-"+ref.get().p);
}
}
class RefThread extends Thread{
private Ref ref;
public RefThread(Ref ref){
this.ref = ref;
}
@Override
public void run() {
for (int i = 0 ; i < 2 ; i++) {
ref.printAddress();
ref.change();
ref.printAddress();
}
}
}
我们在A类中添加了一个int类型的p变量，那么我们多线程操作这个变量，能做到隔离吗？我们看下结果：
Thread-0-com.loubinfeng.A@6d8b82ec-0
Thread-1-com.loubinfeng.A@6d8b82ec-0
Thread-0-com.loubinfeng.A@6d8b82ec-1
Thread-1-com.loubinfeng.A@6d8b82ec-2
Thread-0-com.loubinfeng.A@6d8b82ec-2
Thread-1-com.loubinfeng.A@6d8b82ec-2
Thread-0-com.loubinfeng.A@6d8b82ec-3
Thread-1-com.loubinfeng.A@6d8b82ec-4
很明显，结果差强人意，因为操作的是同一内存，如果要达到p变量的隔离效果，只需要微调下，如下：
class Ref{
private static A a = new A();
private static ThreadLocal ref = new ThreadLocal(){
@Override
protected A initialValue() {
return a;
}
};
public void change(){
A a = new A();
a.p = ref.get().p+1;
ref.set(a);
}
public void printAddress(){
System.out.println(Thread.currentThread().getName()+"-"+ref.get()+"-"+ref.get().p);
}
}
Thread-0-com.loubinfeng.A@14e672aa-0
Thread-0-com.loubinfeng.A@1a218e46-1
Thread-0-com.loubinfeng.A@1a218e46-1
Thread-0-com.loubinfeng.A@1e1e19da-2
Thread-1-com.loubinfeng.A@14e672aa-0
Thread-1-com.loubinfeng.A@45669fee-1
Thread-1-com.loubinfeng.A@45669fee-1
Thread-1-com.loubinfeng.A@4ba17932-2
这个例子想说明，使用ThreadLocal，变量又是引用类型时，请注意变量的内存地址，因为变量副本复制是引用，而不是真正的内存。
ThreadLocal工作原理及api
看到这里，大家一定对ThreadLocal的工作原理很好奇。它是怎么做到变量的隔离而没有涉及变量的共享同步。
因为线程同步机制是多线程共享同一个变量，而ThreadLocal是为每一个线程创建一个单独的变量副本，所以每个线程都可以独立的改变自己所拥有的变量副本，同时还不影响其他线程的对应副本。
ThreadLocal定义了4个方法供开发者调用：
- get()：返回此线程局部变量的当前线程副本中的值。
- initialValue()：返回此线程局部变量的当前线程的“初始值”。
- remove()：移除此线程局部变量当前线程的值。
- set(T value)：将此线程局部变量的当前线程副本中的值设置为指定值。
ThreadLocal，ThreadLocalMap和Thread之间关系
再探究ThreadLocal工作机制源码之前，我们先要搞清ThreadLocal，ThreadLocalMap和Thread三者的角色关系。
- ThreadLocalMap是ThreadLocal的一个内部类
- 每一个Thread对象中都有一个ThreadLocalMap类型的变量，用来存储变量副本
- ThreadLocalMap的key是ThreadLocal类型的，value是变量类型。
补充下，ThreadLocalMap是实现变量副本机制的关键类。突然出现这个类，估计一头雾水，下节我们讲探究源码，大家会对这个类有进一步的了解。
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);
}
这是ThreadLocal的set方法的源码实现，实现逻辑是非常清晰的，先获取到了当前的线程对象，然后得到线程内部的ThreadLocalMap对象，如果是空的话，就创建这个对象。不是空的话，就将值存入这个map中，key则为当前这个ThreadLocal对象。
private void set(ThreadLocal key, Object value) {
// We don't use a fast path as with get() because it is at
// least as common to use set() to create new entries as
// it is to replace existing ones, in which case, a fast
// path would fail more often than not.
Entry[] tab = table;
int len = tab.length;
int i = key.threadLocalHashCode & (len-1);
for (Entry e = tab[i];
e != null;
e = tab[i = nextIndex(i, len)]) {
ThreadLocal k = e.get();
if (k == key) {
e.value = value;
return;
}
if (k == null) {
replaceStaleEntry(key, value, i);
return;
}
}
tab[i] = new Entry(key, value);
int sz = ++size;
if (!cleanSomeSlots(i, sz) && sz >= threshold)
rehash();
}
这个是ThreadLocalMap的set方法，跟随上面的思路，ThreadLocal的set方法最终执行了ThreadLocalMap的set方法。这里要说明的是，虽然都是key-value结构，但是和集合Map解决散列冲突的方式是不一样的。集合Map的put采用是拉链式的，而ThreadLocalMap的set采用的是开放定址法。
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();
}
这是ThreadLocal的get方法，跟他的set方法如出一辙，也是先得到线程对象，在获取Thread中的ThreadLocalMap对象，然后根据key取值，如果map为空，直接返回ThreadLocal 的初始值。
/**
* Get the entry associated with key. This method
* itself handles only the fast path: a direct hit of existing
* key. It otherwise relays to getEntryAfterMiss. This is
* designed to maximize performance for direct hits, in part
* by making this method readily inlinable.
*
* @param key the thread local object
* @return the entry associated with key, or null if no such
*/
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);
}
/**
* Version of getEntry method for use when key is not found in
* its direct hash slot.
*
* @param key the thread local object
* @param i the table index for key's hash code
* @param e the entry at table[i]
* @return the entry associated with key, or null if no such
*/
private Entry getEntryAfterMiss(ThreadLocal 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;
}
当然追踪get方法，最终还是执行到了ThreadLocalMap的getEntry方法。如果所对应的key就是我们要找的元素，则返回，否则就调用getEntryAfterMiss方法。
这部分源码就不过分展开了，大略介绍下。
ThreadLocal方法的缺陷
ThreadLocal会存在内存泄漏的情况。因为每个Thread都有一个ThreadLocalMap实例，这个map的key类型是ThreadLocal，但是是个弱引用。弱饮用有利于GC回收。当这个key为null时，GC就会回收这部分空间，但是value却不一定被回收，因为有可能他和当前线程还存在强引用关系。这就是问题所在。
当然源码中也考虑到了这种情况，已经做了很多优化的地方，但是还是不能100%避免。这是我们就要显示的调用ThreadLocal的remove方法进行处理。
总结
ThreadLocal是解决多线程变量问题的另一种思路，核心理念就是为每个线程创建变量副本，用空间换时间的思路。