ThreadLocal是一个线程内部的数据存储类，它用来存储那种---以线程为作用域并且不同线程具有不同的数据副本的这类数据。
如果没有这个东西，如果我们要实现线程隔离的一些数据副本的存储，该怎么做？我们会创建一个当前进程下的，全局哈希表。这个哈希表对所有线程可见。但是这样做会有三个问题：
- 需要为每个存储的对象都创建一个哈希表，比如面向Looper的哈希表和面向某个String对象的哈希表。亦或是只用一个哈希表，但是哈希表里的桶，需要预估存储的数据量和数据类型，然后采用相应的存储结构。
- 既然是当前虚拟机内所有的线程可见，那就需要处理并发读写的问题，涉及到加锁，容易出错。
于是相比较之下，还是ThreadLocal的方案更优雅。
在这个基础上还可以解决复杂逻辑下的对象传递，比如传递监听器。
否则只能直接通过参数的形式传递监听器或者把监听器定义成静态变量。前者在调用栈很深的时候无法接受，后者不具备可扩展性，可能会有很多静态监听器对象。
它的大致结构是如下图这样的：
每个线程Thread会持有一个ThreadLocalMap对象，这个对象是一个长度为16的数组，数组里存放我们刚刚说的数据副本。这个数组的桶里是一个K,V对，key是我们创建的ThreadLocal对象本身，value就是真正存储的数据。也就是说每个线程能存放的数据量是16个对象。能不能扩展呢，不可以手动扩展，至少在android-28的源码里，是没有扩展的入口的。但是在数据插入超过装载因子的情况下，会进行扩容。
至此这个TL的原理就讲完了，接下来会涉及到android平台相关的一些代码细节来证实，不是必看内容。
它是如何通过这样简单的get和set，完成这种线程间相互隔离的数据存储方案？
先看set方法：
先拿到当前的线程t----然后根据当前线程t来得到当前线程的ThreadLocalMap，如果没有就创建。有的话，就调用set方法，这个this就是我们创建的threadlocal实例，value就是具体的数据。
这里值得一提的是，这个K，V对，里的key也就是ThreadLocal的实例，是被弱引用的。
目的就是在threadlocal被回收的时候，能清除掉数组里的过期槽位（所谓过期槽位就是key为null的槽）。
这个ThreadLocalMap是线程Thread持有的一个成员变量。
由此对应到上面那张我手画的图，每个Thread持有一个ThreadLocalMap。
看下map的创建：
它只有一个构造函数，且没有提供设置初始化数组大小的入口，所以我说这个16的初始值没法手动修改。但是如果set的数据超过装载因子，就会进行rehash。
这个threshold的值是size的三分之二：
然后我们再看下rehash：
如上图，超过装载因子以后会扩容成原来的2倍大。即新建一个两倍大的数组，然后把原始拷贝过去，这个过程和arraylist的扩容操作类似，其实数组这中结构，扩容的办法都是这样的，先复制，再拷贝。
回到刚刚的set方法，补充一句，是先对key进行hash，之后计算出理论的槽位，然后尝试放入，槽位为空或者key为null直接覆盖，否则就尝试下一个index（即 用线性探测法解决哈希冲突）。
在ThreadLocal的使用过程中，可能出现内存泄漏和线程不安全的情况。
-
内存泄漏
前面说过了，kv对中的key是用弱引用持有的ThreadLocal的实例，当key被回收以后，value会在下次set的时候被当做过期的槽位清空。
但是这个不够及时，如果没有下个set操作的到来，线程也迟迟不结束，就会存在对value的强引用因为value不会被访问了但是释放不掉导致内存泄漏。只能等当前thread结束以后，强引用被断开，Current Thread、Map value才会全部被GC回收。
最好的办法是在不用这个value以后，手动调用remove主动清空槽位。
这种情况下如何和线程池配合使用，需要格外小心，因为线程池里的线程一直不断的重复运行，可能造成value堆积，更需要及时调用remove了。 -
线程不安全
这个线程不安全，翻译过来就是，能在A线程里的ThreadLocal更改B线程里的ThreadLocal。
应该避免这种情况，即不同线程里的ThreadLocal持有同一个对象（静态对象）（static修饰的类在JVM中只保存一个实例对象）。
总结提炼一下，ThreadLocal的意义是什么？回顾文章开头我对比哪个全局哈希表的解决方案。其实ThreadLocal是解决线程安全的一个好办法，为每个线程提供了独立的变量副本解决了线程共享变量并发访问的问题。这个并发访问就会涉及到JVM同步锁。用JVM同步锁来解决开发中的这类为题也完全可以，一个是空间换时间，一个是时间换空间。
到这里这个ThreadLocal就讲完了，欢迎交流。
