这是ThreadLocal系列的最后一篇文章。
前几篇文章更多的是在使用层面去介绍ThreadLocal，并没有深入去理解原理。
其实学任何技术都是这样一个过程，我们最先接触到的可能是一个框架的API，然后你可能就会开始使用它；再然后会看看别人是怎么使用它的，有没有值得借鉴之处，再然后就是深入原理，看看它的底层是如何实现的，对它做一个深入的了解。
下面我们进入正题，先分析一下ThreadLocal几个重要的方法。
set
set方法其实很短，我们先看一下代码：
public void set(T value) { Thread t = Thread.currentThread(); ThreadLocalMap map = getMap(t); if (map != null) { map.set(this, value); } else { createMap(t, value); } }
先拿到当前的线程，然后通过它去拿到一个Map，如果这个Map存在，就把value塞进去，否则就创建一个新的。
ThreadLocalMap是在ThreadLocal类里面实现的一个Map，它的Entry是一个弱引用的实现。
static class Entry extends WeakReference<ThreadLocal<?>>
每个线程对应一个自己线程私有的ThreadLocalMap，它被Thread对象持有：
// 类Thread里面定义了ThreadLocalMap的引用 ThreadLocal.ThreadLocalMap threadLocals = null;
从set方法的代码可以看到，最开始线程的threadLocals可能是空，这个时候就创建一个新的，赋值给当前线程对象：
void createMap(Thread t, T firstValue) { t.threadLocals = new ThreadLocalMap(this, firstValue);
get
看完上面的分析后，get方法就很好理解了。仍然是先通过getMap方法拿到当前线程对应的Map，然后从里面取出value。如果没有value，就调用ThreadLocal提供的初始化方法，初始化一个值。
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定义的的初始化方法，看起来就是一个很简单的protected方法：
protected T initialValue() { return null; }
而为了更方便用户使用，ThreadLocal自己内部有一个ThreadLocal的实现类，它提供了一个函数式编程的方式来让客户端更方便地使用：
static final class SuppliedThreadLocal<T> extends ThreadLocal<T> { private final Supplier<? extends T> supplier; SuppliedThreadLocal(Supplier<? extends T> supplier) { this.supplier = Objects.requireNonNull(supplier); } @Override protected T initialValue() { return supplier.get(); } }
我们甚至可以依样画葫芦，自己新建一个FunctionedThreadLocal，实现更多的定制化。
remove
remove方法不得不提。首先我们思考一下，既然已经有了弱引用，按理说，如果线程没有持有某个value的时候，会在GC的时候自动清理掉对应的Entry，为什么会有remove方法存在？
因为我们在开发一个多线程的程序时，往往会使用线程池。而线程池的功能就是线程的复用。那如果线程池和ThreadLocal在一起就可能会造成一个问题：
- job A和job B共用了同一个线程，
- job A使用完ThreadLocal，ThreadLocal里面还有job A保存的值，而这个时候可能还没有清理掉，
- job B复用线程进来了，取出来是 job A的值，可能就会造成问题。
所以在有必要的时候，可以在使用完ThreadLocal的时候，显式调用一下remove方法。remove方法的源码也比较简单，就是调用对应的entry的clear方法。
public void remove() { ThreadLocalMap m = getMap(Thread.currentThread()); if (m != null) { m.remove(this); } } private void remove(ThreadLocal<?> key) { 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)]) { if (e.get() == key) { e.clear(); expungeStaleEntry(i); return; } } }
学习借鉴
这里总结出我们从ThreadLocal的设计中可以学习借鉴的一些点。
避免并发
这个其实挺有意思的。如果让我们自己来设计一个ThreadLocal，想要拿到当前线程对应的ThreadLocalMap，可能就会用一个Map来存这个关系：
Map<Thread, ThreadLocalMap> threadLocalMaps = new ConcurrentHashMap<>();
因为可能会有多个线程同时调用get/set方法，所以还需要对这个Map来做一些措施来保证线程安全，比如使用ConcurrentHashMap，甚至复杂的原子操作可能还需要上锁。这样其实对性能是不利的。
而JDK巧妙地把这个引用直接放到了Thread对象里面，使得多个线程不需要同时操作同一个对象。所以我们在设计代码的时候，也要有这种思维的转变。并不是说我想实现一个工具类，就一定要把所有的代码都写在这个工具类里面。要充分考虑怎样设计更合理，性能更高。
弱引用
使用弱引用可以让GC及时回收掉程序中不需要使用的对象。这个刚好适用于ThreadLocal的场景。因为很多时候线程执行完后，就销毁了。如果让我们显示去调用一个方法，就会变得非常麻烦。而且一旦忘记回收，还有可能撑满内存。
所以这点ThreadLocal做得很好，利用了弱引用的特性，与Java的设计哲学一致：你只管用，回收的事情我帮你做了！
❝Tips: 这里需要注意上面提到的与线程池一起使用可能存在的问题哦。
❞
简单设计
ThreadLocal中自己定义了一个很简单的可以自动扩容的Map。它处理冲突的方式与HashMap不一样，HashMap是数组 + 链表/红黑树的方式来处理哈希冲突，而ThreadLocal实现得更简单，使用的是「开放地址法」，如果发生了冲突，就寻找下一个有空的位置。
开放地址法虽然效率不一定高，但胜在实现起来很简单，用在这里绰绰有余。我们在设计数据结构和算法的时候，甚至是在设计程序的时候，也有遵循够用、简单就行的原则，不用太过度设计。也就是我们常说的KISS原则：Keep it stupid and simple。
函数式编程
使用函数式编程可以让客户端更简单地实现定制化。比如ThreadLocal中的初始化方法，如果没有函数式编程，我们首先得新建一个ThreadLocal的继承类，然后复写它的initialValue方法，用起来特别不方便。
我们在设计自己的工具类的时候，想要实现一定程度的灵活性和定制化，就可以考虑利用函数式编程的便利。
巧用this
this其实我们平时用的还算比较多，最多的地方应该是POJO类了。但ThreadLocal进行了一个骚操作。
我们看ThreadLocalMap的源码可以发现，它的key类型就是ThreadLocal。我们在调用get/set方法的时候，就会使用this。
为什么要这么设计？你会发现Thread和ThreadLocal其实是「多对多的关系」。一个Thread可能会用到多个ThreadLocal，而一个ThreadLocal又同时给多个Thread用。那么问题来了，我们的入口是ThreadLocal对象，那如何能够快速地拿到当前Thread，当前ThreadLocal的value？
这就是this的关键之处了，我先拿到当前Thread，然后通过Thread里面保存的引用，拿到ThreadLocalMap，这个Map里面保存了此线程对应的所有ThreadLocal的对象，key就是这个对象本身，所以用this作为key，可以快速找到当前ThreadLocal对应的value。
假如我们要实现一个多对多的场景，比如一个学生有多个老师，一个老师有多个学生。通过学生类作为入口进去，如何能够快速获取一个学生指定老师的分数？我们写个程序来模拟一下：
// 教师类 public class Teacher { // 每个教师保存了自己每个学生的分数 Map<Student, Integer> scores = new HashMap<>(); public Map<Student, Integer> getScores() { return scores; } } // 学生类 public class Student { public int get(Teacher teacher) { Map<Student, Integer> scores = teacher.getScores(); return scores.get(this); } public void set(Teacher teacher, int score) { teacher.getScores().put(this, score); Map<Student, Integer> scores = teacher.getScores(); } }
当然了，这种场景其实并不多见。但ThreadLocal有它的特殊性，首先当前Thread对象是可以通过全局直接获取到的，然后我们的操作入口一般是ThreadLocal，使用而不是Thread。
试想一下，其实如果JDK开放权限，通过Thread也能拿到最后的ThreadLocal，无非就是麻烦一些：大概长这样：
Thread thread = Thread.currentThread(); // 如果jdk提供下面这个方法 ThreadLocalMap threadLocalMap = thread.getThreadLocals(); threadLocalMap.set(threadLocal, value); // set Object value = threadLocalMap.get(threadLocal); // get
但是这样一看，显然不如现在这样设计得优雅：
threadLocal.set(value); //set Object value = threadLocal.get(); // get
所以这就是程序设计的哲学，大佬设计出来的东西，就是好用！JDK把ThreadLocal的引用放到了Thread里面，让它能够避免多个线程争用资源，再巧妙利用了this关键字，让你可以很简单地使用它。然后还考虑到了内存回收的问题，用弱引用帮你解决。
看完ThreadLocal源码不禁惊呼：只怪自己没文化，一句卧槽走天下！
