ThreadLocal是Handler涉及到的一个非常重要的类，其主要作用是：通过ThreadLocal实例变量，可以再不同的线程中，访问到不同的实例。
在实际开发需求中，我们可能需要不同的线程，持有仅属于其自己的变量，也是就这个线程自己特有的变量，换句话说，就是线程类自己的私有属性。
比如说，我们希望各个线程都有一个变量ID，那么可以这样处理：
// 新建一个类，继承与Thread，然后再里头加一个private变量ID
// 这样每个不同的MyThread线程实例，里头都有个ID，且互不影响
public class MyThread extends Thread {
private int ID;
}
显然这种实际上可操作性很差的：
1.并不是所有的线程实例都是MyThread，那其他的线程咋办呢？
2.实际应用中显然并不是只需要ID，要是还要个name、还要个age呢？
考虑到实际场景，JDK为大家已经在线程里加了这么一个变量：
public class Thread implements Runnable {
/* ThreadLocal values pertaining to this thread. This map is maintained
* by the ThreadLocal class. */
ThreadLocal.ThreadLocalMap threadLocals = null;
}
ThreadLocal.ThreadLocalMap就是专业用于上述场景的，从名字上来看，他是一个Map，所以可以根据需求来添加多个变量。
如果只是这样，那我们实际应该怎么用呢？
我们可以这样：
- 确定需要读取的Key，比如说“ID”。
- 获取到当前线程的实例，读取threadLocals里key为"ID"的对象。
- 对其进行读写操作。
public static void main(String[] args){
final static String keyID = "ID";
new Thread(new Runnable() {
@Override
public void run() {
// 模拟读值
String id = Thread.currentThread().threadLocals.getValue(keyID);
// 模拟取值
Thread.currentThread().threadLocals.setValue(keyID,"ID_1");
}
}).start();
}
自然，这样的代码显然编译不过的，threadLocals是Thread的一个私有变量，无法直接被外部操作，JDK已经给我们封装号了一个类ThreadLocal，通过ThreadLocal，可以轻松的完成上述操作：
ThreadLocal<String> local = new ThreadLocal<>();
local.set("ID_1");
String ID = local.get();
我们可以先看下ThreadLocal中get()、set()方法的源码：
从map.getEntry(key:this)上可知，线程中取值的key是ThreadLocal<?>，那么自然，不同类型的ThreadLocal<?>，会有在线程成员变量Thread.threadLocals中占有不同的位置。
其结构如下：
每一个ThreadLocal<?>对象，存放到多个线程里的threadLocals中，而其所对应的Value，则是各个线程独立的。
到这里基本上说完了ThreadLocal的作用和结构，我们先看下大神是如何描述ThreadLocal的：
ThreadLocal 提供了线程本地的实例。它与普通变量的区别在于，每个使用该变量的线程都会初始化一个完全独立的实例副本。ThreadLocal 变量通常被private static修饰。当一个线程结束时，它所使用的所有 ThreadLocal 相对的实例副本都可被回收。
为什么建议修饰成private static呢？按我理解：
- 一个ThreadLocal实例，可以对应到一票线程，每个线程都持有各自的TSO实例（Thread Specific Object，即ThreadLocal所关联的对象，如ThreadLocal<String>里的String对象）。因此，如果ThreadLocal不是某个类的静态变量，那么每创建一个该类的实例，就有一个新的ThreadLocal被创建，也就是一票新的TSO实例可能被创建。那么，同一个线程可能有多个由同一个TSO（指类）产生的不同实例。这就算不会导致错误，也会导致浪费（重复创建等同的对象）！而且也和我们预期不符，我们希望的是线程特有，而不是实例特有。
- static变量不属于任何一个对象，这样ThreadLocal<?>在被线程持有时，由于在android中静态类型一般不被回收，故不容易产生由ThreadLocal<?>所在类引起的内存泄漏。
言归正传，继续将ThreadLocal源码，从前问的get、set方法，我们知道，真正线程中存储数据的数据结构是ThreadLocalMap，接下来就分析这个类，先看保持数据的数据结构：
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;
}
}
/**
* The table, resized as necessary.
* table.length MUST always be a power of two.
*/
private Entry[] table;
}
显然，这个Map与其他Map类似，都是一个数组，还是个Entry的数组。Entry是一个ThreadLocal<?>的弱引用，对照着前文的set()方法，value就是ThreadLocal<?>里的类型T，这么设计的目的，主要不让线程强引用ThreadLocal<?>，导致ThreadLocal<?>所在的类或实例不再使用时，无法被释放，从而引起内存泄露。需要指出的是，仅仅是这样，Object value依旧可以内存泄露，Entry的ThreadLocal<?>属性被释放，无法影响到其对应的value，所以JDK还会在合适的时候，清理key为null的value。先看get方法：
暂时不理问题，先看完expungeStaleEntry方法的实现：
需要指出的是threadLocalHashCode & (len-1) 和 threadLocalHashCode%len在数学上也是等价的（len为2的次方时），感兴趣的可以自行证明下。
接着前面的疑问，看下set的方法：
到这里，ThreadLocalMap基本操作和结构就都弄清楚了，这些操作虽然没有加上线程同步等相关代码，但由于ThreadLocalMap本身就是只运行在单个线程里的，所以他们天然就不涉及多线程场景，也就不谈什么线程同步了。
