#### 10.2.1 ThreadLocal的工作原理 [ThreadLocal](https://www.androidos.net.cn/android/6.0.1_r16/xref/libcore/luni/src/main/java/java/lang/ThreadLocal.java)是一个**线程内部的数据存储类**，通过它可以**在指定的线程中存储数据，数据存储以后，只有在指定线程中可以获取到存储的数据，对于其他线程来说则无法获取到数据**。 * [ ] **ThreadLocal的使用场景** 在日常开发中用到ThreadLocal的地方较少，但是在某些特殊的场景下，通过ThreadLocal可以轻松地实现一些看起来很复杂的功能，这一点在Android的源码中也有所体现，比如Looper、ActivityThread以及AMS中都用到了ThreadLocal。具体到ThreadLocal的使用场景，这个不好统一来描述，**一般来说，当某些数据是以线程为作用域并且不同线程具有不同的数据副本的时候，就可以考虑采用ThreadLocal**。比如*对于Handler来说，它需要获取当前线程的Looper，很显然Looper的作用域就是线程并且不同线程具有不同的Looper，这个时候通过ThreadLocal就可以轻松实现Looper在线程中的存取。如果不采用ThreadLocal，那么系统就必须提供一个全局的哈希表供Handler查找指定线程的Looper，这样一来就必须提供一个类似于LooperManager的类了，但是系统并没有这么做而是选择了ThreadLocal，这就是ThreadLocal的好处*。 **ThreadLocal另一个使用场景是复杂逻辑下的对象传递**，比如*监听器的传递，有些时候一个线程中的任务过于复杂，这可能表现为函数调用栈比较深以及代码入口的多样性，在这种情况下，我们又需要监听器能够贯穿整个线程的执行过程，这个时候可以怎么做呢？其实这时就可以采用ThreadLocal，采用ThreadLocal可以让监听器作为线程内的全局对象而存在，在线程内部只要通过get方法就可以获取到监听器*。 如果不采用ThreadLocal，那么我们能想到的可能是如下两种方法： * 第一种方法是将监听器通过参数的形式在函数调用栈中进行传递， * 第二种方法就是将监听器作为静态变量供线程访问。 上述**这两种方法都是有局限性的**。 * 第一种方法的问题是当函数调用栈很深的时候，通过函数参数来传递监听器对象这几乎是不可接受的，这会让程序的设计看起来很糟糕。 * 第二种方法是可以接受的，但是这种状态是不具有可扩充性的，比如同时有两个线程在执行，那么就需要提供两个静态的监听器对象，如果有10个线程在并发执行呢？提供10个静态的监听器对象？这显然是不可思议的，而**采用ThreadLocal，每个监听器对象都在自己的线程内部存储，根本就不会有方法2的这种问题**。 * [ ] **ThreadLocal的示例** 介绍了那么多ThreadLocal的知识，可能还是有点抽象，下面通过实际的例子来演示ThreadLocal的真正含义。首先定义一个ThreadLocal对象，这里选择Boolean类型的，如下所示。 ``` private ThreadLocal<Boolean> mBooleanThreadLocal = new ThreadLocal<Boolean>(); ``` 然后分别在主线程、子线程1和子线程2中设置和访问它的值，代码如下所示。 ``` mBooleanThreadLocal.set(true); Log.d(TAG, "[Thread#main]mBooleanThreadLocal=" + mBooleanThreadLocal.get()); new Thread("Thread#1") { @Override public void run() { mBooleanThreadLocal.set(false); Log.d(TAG, "[Thread#1]mBooleanThreadLocal=" + mBooleanThreadLocal. get()); }; }.start(); new Thread("Thread#2") { @Override public void run() { Log.d(TAG, "[Thread#2]mBooleanThreadLocal=" + mBooleanThreadLocal. get()); }; }.start(); ``` 在上面的代码中，在主线程中设置mBooleanThreadLocal的值为true，在子线程1中设置mBooleanThreadLocal的值为false，在子线程2中不设置mBooleanThreadLocal的值。然后分别在3个线程中通过get方法获取mBooleanThreadLocal的值，根据前面对ThreadLocal的描述，这个时候，**主线程中应该是true，子线程1中应该是false，而子线程2中由于没有设置值，所以应该是null**。安装并运行程序，日志如下所示。 ``` D/TestActivity(8676): [Thread#main]mBooleanThreadLocal=true D/TestActivity(8676): [Thread#1]mBooleanThreadLocal=false D/TestActivity(8676): [Thread#2]mBooleanThreadLocal=null ``` 从上面日志可以看出，**虽然在不同线程中访问的是同一个ThreadLocal对象，但是它们通过ThreadLocal获取到的值却是不一样的**，这就是ThreadLocal的奇妙之处。结合这个例子然后再看一遍前面对ThreadLocal的两个使用场景的理论分析，我们应该就能比较好地理解ThreadLocal的使用方法了。**ThreadLocal之所以有这么奇妙的效果，是因为不同线程访问同一个ThreadLocal的get方法，ThreadLocal内部会从各自的线程中取出一个数组，然后再从数组中根据当前ThreadLocal的索引去查找出对应的value值**。很显然，**不同线程中的数组是不同的，这就是为什么通过ThreadLocal可以在不同的线程中维护一套数据的副本并且彼此互不干扰**。 * [ ] **ThreadLocal的内部实现** 对ThreadLocal的使用方法和工作过程做了介绍后，下面分析**ThreadLocal的内部实现**，**ThreadLocal是一个泛型类**，它的定义为`public class ThreadLocal<T>`，只要弄清楚ThreadLocal的get和set方法就可以明白它的工作原理。 首先看ThreadLocal的set方法，如下所示。 ``` public void set(T value) { Thread currentThread = Thread.currentThread(); //获取当前线程 Values values = values(currentThread); //查找当前线程的本地储存区 if (values == null) { //当线程本地存储区，尚未存储该线程相关信息时，则创建Values对象 values = initializeValues(currentThread); } //保存数据value到当前线程this values.put(this, value); } ``` 在上面的set方法中，**首先会通过values方法来获取当前线程中的ThreadLocal数据**，如何获取呢？其实获取的方式也是很简单的，**在Thread类的内部有一个成员专门用于存储线程的ThreadLocal的数据：`ThreadLocal.Values localValues`，因此获取当前线程的ThreadLocal数据就变得异常简单了。如果`localValues`（其实就是`ThreadLocal.Values`）的值为null，那么就需要对其进行初始化，初始化后再将ThreadLocal的值进行存储**。 下面**看一下ThreadLocal的值到底是如何在localValues中进行存储的。在localValues内部有一个数组：private Object[] table, ThreadLocal的值就存在在这个table数组中**。 下面看一下localValues是如何使用put方法将ThreadLocal的值存储到table数组中的，如下所示。 ``` void put(ThreadLocal<?> key, Object value) { cleanUp(); // Keep track of first tombstone. That's where we want to go back // and add an entry if necessary. int firstTombstone = -1; for (int index = key.hash & mask;; index = next(index)) { Object k = table[index]; if (k == key.reference) { // Replace existing entry. table[index + 1] = value; return; } if (k == null) { if (firstTombstone == -1) { // Fill in null slot. table[index] = key.reference; table[index + 1] = value; size++; return; } // Go back and replace first tombstone. table[firstTombstone] = key.reference; table[firstTombstone + 1] = value; tombstones--; size++; return; } // Remember first tombstone. if (firstTombstone == -1 && k == TOMBSTONE) { firstTombstone = index; } } } ``` 上面的代码**实现了数据的存储过程，这里不去分析它的具体算法**，但是我们可以得出一个存储规则，那就是**ThreadLocal的值在table数组中的存储位置总是为ThreadLocal的reference字段所标识的对象的下一个位置**，比如ThreadLocal的reference对象在table数组中的索引为index，那么ThreadLocal的值在table数组中的索引就是`index+1`。最终ThreadLocal的值将会被存储在table数组中：`table[index + 1] = value`。 上面分析了ThreadLocal的set方法，这里**分析它的get方法**，如下所示。 ``` @SuppressWarnings("unchecked") public T get() { Thread currentThread = Thread.currentThread(); //获取当前线程 Values values = values(currentThread); //查找当前线程的本地储存区 if (values != null) { Object[] table = values.table; int index = hash & values.mask; if (this.reference == table[index]) { return (T) table[index + 1]; //返回当前线程储存区中的数据 } } else { //创建Values对象 values = initializeValues(currentThread); } return (T) values.getAfterMiss(this); //从目标线程存储区没有查询是则返回null } ``` 可以发现，ThreadLocal的get方法的逻辑也比较清晰，它同样是取出当前线程的local-Values对象，如果这个对象为null那么就返回初始值，初始值由ThreadLocal的`initializeValues`方法来描述，默认情况下为null，当然也可以重写这个方法，它的默认实现如下所示。 ``` /** * Creates Values instance for this thread and variable type. */ Values initializeValues(Thread current) { return current.localValues = new Values(); } ``` **如果localValues对象不为null，那就取出它的table数组并找出ThreadLocal的reference对象在table数组中的位置，然后table数组中的下一个位置所存储的数据就是ThreadLocal的值**。 **从ThreadLocal的set和get方法可以看出，它们所操作的对象都是当前线程的localValues对象的table数组，因此在不同线程中访问同一个ThreadLocal的set和get方法，它们对ThreadLocal所做的读/写操作仅限于各自线程的内部，这就是为什么ThreadLocal可以在多个线程中互不干扰地存储和修改数据**，理解ThreadLocal的实现方式有助于理解Looper的工作原理。 ThreadLocal的get()和set()方法操作的类型都是泛型，接着回到前面提到的sThreadLocal变量，其定义如下： ``` static final ThreadLocal sThreadLocal = new ThreadLocal() ``` 可见sThreadLocal的get()和set()操作的类型都是Looper类型。 参考文章：[Android消息机制](http://gityuan.com/2015/12/26/handler-message-framework/#21-prepare)