首先说说与ThreadLocal相识的背景。在项目中，service有一些逻辑处理{如对主从延迟敏感的下单逻辑}需要强制走主库的。就查了查公司数据库框架zebra强制走主库的方式，发现其主要就是在业务线程的context中写入了一个ThreadLocal<Boolean>变量，当要进行SQL路由时，根据此变量来判断是否需要强制走主库。
首先，如上图所示，Java内存模型JMM如上图所示，每个Java通过自己的缓存与主内存相连接。当需要读写某对象或变量时，需要到主内存copy到线程内，操作完再写回主内存。那么，这些非原子性的操作就很容易引起数据不一致的问题。ThreadLocal就是用解决此问题的，顾名思义，ThreadLocal就是线程局部变量的意思，其使用方式与调用普通POJO数据对象无异，即使用get/set来进行赋值或读取。然而其在存储上，却隐含了线程私有存储之意，线程之间相互隔离，互不影响，从而实现线程安全。先来个使用样例，直接给出zebra的强制走主库的工具类实现：
public class LocalContextReadWriteStrategy implements ReadWriteStrategy {
private static InheritableThreadLocal<Boolean> forceMaster = new InheritableThreadLocal<Boolean>();
@Override
public boolean shouldReadFromMaster() {
Boolean shouldReadFromMaster = forceMaster.get();
if (shouldReadFromMaster == null || !shouldReadFromMaster) {
return false;
} else {
return true;
}
}
protected static void setReadFromMaster() {
forceMaster.set(true);
}
protected static void clearContext() {
forceMaster.remove();
}
@Override
public void setGroupDataSourceConfig(GroupDataSourceConfig config) {
}
}
如上，通过一个ThreadLocal<Boolean>型的线程局部变量forceMaster，通过set()来为其赋值，get()来取值，remove()来实现clear。接下来就来看看这三个方法的实现。ThreadLocal.set()方法实现如下：
public void set(T value) {
Thread t = Thread.currentThread(); // 获取当前线程
ThreadLocalMap map = getMap(t); // 获取线程内部藏着的map
if (map != null)
map.set(this, value); // 以ThreadLocal对象自身为key，将value存放到map中
else
createMap(t, value);
}
ThreadLocalMap getMap(Thread t) {
return t.threadLocals;
}
void createMap(Thread t, T firstValue) {
t.threadLocals = new ThreadLocalMap(this, firstValue);
}
从上面的set方法可以看出：
1. Thread内部有了隐藏的ThreadLocalMap负责存放该线程的ThreadLocal变量，这个是ThreadLocal自定义的map，与HashMap有较大的区别，后续再讨论
2. 第一次调用set的时候，才会创建并初始化这个ThreadLocalMap
3. ThreadLocalMap是以ThreadLocal对象自身作为key的
ThreadLocal的get方法实现如下：
public T get() {
Thread t = Thread.currentThread();
ThreadLocalMap map = getMap(t);
if (map != null) {
ThreadLocalMap.Entry e = map.getEntry(this);
if (e != null)
return (T)e.value;
}
return setInitialValue();
}
ThreadLocal的remove方法如下：
public void remove() {
ThreadLocalMap m = getMap(Thread.currentThread());
if (m != null)
m.remove(this);
}
其实，通过上面的几个方法，已经可以看出来了，对于ThreadLocal变量的存取，关键就在于这个ThreadLocalMap了。set时无非是以ThreadLocal对象自身为key将value存放到map中，而get时，就是以ThreadLocal作为key去map中查找。接下来，就重点瞧瞧这个Thread内部偷偷藏着的自定义map--ThreadLocalMap。
ThreadLocalMap是定义在ThreadLocal中的一个静态类，主要作为装载线程局部变量的容器。先来看看其map定义的节点Entry:
static class Entry extends WeakReference<ThreadLocal> {
/** The value associated with this ThreadLocal. */
Object value;
Entry(ThreadLocal k, Object v) {
super(k);
value = v;
}
}
很有意思，Entry中只定义了一个value，没再定义key，因为key就是ThreadLocal自身。entry.get()拿到key，即threadLocal，entry.value拿到value。此外，通过super(key)，将entry对key的引用定义为了弱引用。这里就要回忆下Java中的强、软、弱、虚四种引用了。仔细思量下就可以理解了，Entry对于Key[即ThreadLocal对象背身]的引用被定义为虚引用，主要是为了能让ThreadLocal在除了Entry之外再无引用时，被顺利的回收掉。因为Thread对于map的引用，map经底层Entry数据对entry的引用都是强引用，这时候，要是entry对ThreadLocal的引用也是强引用的话，那这个ThreadLocal就无法被回收了，也就造成内存泄漏了。
再来看看第一次调用ThreadLocal.set()时创建map的constructor：
ThreadLocalMap(ThreadLocal firstKey, Object firstValue) {
table = new Entry[INITIAL_CAPACITY];
int i = firstKey.threadLocalHashCode & (INITIAL_CAPACITY - 1);
table[i] = new Entry(firstKey, firstValue);
size = 1;
setThreshold(INITIAL_CAPACITY);
}
这里面就涉及到ThreadLocal的hashcode的计算了：
private static final int HASH_INCREMENT = 0x61c88647;
private final int threadLocalHashCode = nextHashCode();
private static AtomicInteger nextHashCode = new AtomicInteger();
private static int nextHashCode() {
return nextHashCode.getAndAdd(HASH_INCREMENT);
}
上面的几行代码就已经完成了一个ThreadLocal对象的哈希值的计算了：
1. hash值在thread对象创建时就已经计算好了，后续不再发生变化
2. 以神奇的魔数 0x61c88647 作为递增量，来计算新ThreadLocal对象的hash值（这个魔数在各类SDK中经常被用到，原因是据此递增出来的hash值在2的N次方的长度的链表中分布非常均匀）
再来看看ThreadLocalMap的set方法：
private void set(ThreadLocal key, Object value) {
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();
}
private static int nextIndex(int i, int len) {
return ((i + 1 < len) ? i + 1 : 0);
}
上面的set方法有几个有意思的地方：
1. hash冲突，其使用了线性探测法而非HashMap中的链表法来解决hash冲突
2. 判空，前面说了，Entry对于key的引用是个弱引用，因此当拿出来Entry之后发现key=null了，说明作为key的ThreadLocal已经被回收了，这个节点也就是个过时的节点了，需要被处理掉了
3. 在Java1.3中，存放ThreadLocal的那个map，使用了HashMap来实现，后来为了性能，变更为自定义map
至此，已然有所得了~