这篇文章会详细阐述ThreadLocal的内部结构及其原理，以及神奇的0x61c88647
在Java 1.4之前，ThreadLocals会产生线程间的竞争，无法写出高性能的代码. Java 1.5改变了它的实现，下面详细阐述ThreadLocal 的内部结构和原理， 并分析为了解决散列表的冲突而引入的神奇的hash code: 0x61c88647
1 ThreadLocal 应用场景
先举个在平时工作中经常用到的场景, 一个web应用供登录用户通过浏览器访问，后台应用会获取用户的登录信息(如用户名)，并对每个用户的访问做记录. 这是一个并发场景，每次请求都分配一个线程去处理这个请求，web容器一般都会有一个线程池，每次请求都会分配其中的一个空闲线程去处理用户的这次请求, 处理完毕后，线程归还线程池等待后续访问的线程分配.
当然，用户登录信息可以从当前请求request中获取，但是后台应用的多个地方可能都会需要用户登录信息， 一个解决办法是向这些所有用到的地方传递request参数，显然是麻烦的。另外一个办法就是利用ThreadLocal, 获取登录信息后把它放到当前线程中的ThradLocal变量中，任何需要的时候从当前线程中取就可以了，是不是很方便呢?
因此ThreadLocal的应用场景应该是实现在不同的线程存储不同的上下文信息的场合中，这样的场合最多的可能就是webapp中，引用stackoverflow中的一个回答:
2 ThreadLocal 原理
因此，ThreadLocal只是提供一个thread-local变量，这个变量于当前线程所独有, 每一个线程都有一个隶属与当前线程的thread-local变量
下面是ThreadLocal对外提供的四个方法:
protected T initialValue()设置并返回当前线程变量的一个初始值set(T value)将信息value放到当前线程的thread-local变量中T get()是获取set(T value)设置的值,如果没有则返回初始值remove()移除线程中的这个thread-local变量
thread-local变量是怎么与当前线程Thread关联的呢? 看一下Thread源码，它有一个实例属性:
/**
* ThreadLocal values pertaining to this thread.
* This map is maintained by the ThreadLocal class.
*/
ThreadLocal.ThreadLocalMap threadLocals = null;
是的，就是ThreadLocal.ThreadLocalMap对象(Thread和ThreadLocal类属于相同的包java.lang). 看来它是用ThreadLocalMap实现的，此时能看出ThreadLocalMap是ThreadLocal类中的一个静态内部类, 也可以看出上面说的thread-local变量其实就是这个threadLocals对象, 下面就看下这个ThreadLocalMap到底长什么样
static class ThreadLocalMap {
static class Entry extends WeakReference<ThreadLocal> {
/** The value associated with this ThreadLocal. */
Object value;
Entry(ThreadLocal k, Object v) {
super(k);
value = v;
}
}
/**
* The initial capacity -- MUST be a power of two.
*/
private static final int INITIAL_CAPACITY = 16;
/**
* The table, resized as necessary.
* table.length MUST always be a power of two.
*/
private Entry[] table;
/**
* Get the entry associated with key.
*/
private Entry getEntry(ThreadLocal key) {...}
/**
* Set the value associated with key.
*/
private void set(ThreadLocal key, Object value) {...}
// æé å1⁄2æ°åå
¶ä»ä ̧äoå1⁄2æ°çç¥
}
可以看出ThreadLocalMap确实是一个map, 通过它的属性Entry[] table实现，而Entry的key是ThreadLocal对象，value是要设置的值，
注意两点:
具体的ThreadLocalMap实例并不是ThreadLocal保持，而是每个Thread持有，且不同的Thread持有不同的ThreadLocalMap实例, 因此它们是不存在线程竞争的(不是一个全局的map)， 另一个好处是每次线程死亡，所有map中引用到的对象都会随着这个Thread的死亡而被垃圾收集器一起收集
Entry的key是对ThreadLocal的弱引用，当抛弃掉ThreadLocal对象时，垃圾收集器会忽略这个key的引用而清理掉ThreadLocal对象， 防止了内存泄漏
总上所述，可以用下面的结构图描述ThreadLocal的工作原理：
当向thread-local变量中设置value时(set(T value))，获取当前Thread中的ThreadLocalMap,如果此时是null，则用ThreadLocal实例和value构建一个map设置到当前线程的属性threadLocals中， 否则通过ThreadLocal对象作为key直接将ThreadLocal实例和value放到当前Thread已存在的map中(可能产生冲突，后面介绍)
当从ThreadLocal变量中获取value时(get()), 获取当前Thread中的ThreadLocalMap, 如果为null则通过initialValue()构建初始值同时利用这个初始值构建一个map到当前Thread中，最后返回这个初始值，否则从map中获取对应的Entry并返回value
通过原理分析可以看出，在使用ThreadLocal是应该将它声明为public static, 即所有线程共用一个ThreadLocal实例，而不是每一个线程来临时都要新创建一个ThreadLocal对象， Java Doc也建议，ThreadLocal应当声明为public static.
3 碰撞解决与神奇的 0x61c88647
既然ThreadLocal用map就避免不了冲突的产生
3.1 碰撞避免和解决
这里碰撞其实有两种类型
只有一个ThreadLocal实例的时候(上面推荐的做法)，当向thread-local变量中设置多个值的时产生的碰撞，碰撞解决是通过开放定址法， 且是线性探测(linear-probe)
多个ThreadLocal实例的时候，最极端的是每个线程都
new一个ThreadLocal实例，此时利用特殊的哈希码0x61c88647大大降低碰撞的几率， 同时利用开放定址法处理碰撞
3.2 神奇的 0x61c88647
注意 0x61c88647 的利用主要是为了多个ThreadLocal实例的情况下用的
从ThreadLocal源码中找出这个哈希码所在的地方
/**
* ThreadLocals rely on per-thread linear-probe hash maps attached
* to each thread (Thread.threadLocals and inheritableThreadLocals).
* The ThreadLocal objects act as keys, searched via threadLocalHashCode.
* This is a custom hash code (useful only within ThreadLocalMaps) that
* eliminates collisions in the common case where consecutively
* constructed ThreadLocals are used by the same threads,
* while remaining well-behaved in less common cases.
*/
private final int threadLocalHashCode = nextHashCode(); /**
* The next hash code to be given out. Updated atomically.
* Starts at zero.
*/
private static AtomicInteger nextHashCode = new AtomicInteger(); /**
* The difference between successively generated hash codes - turns
* implicit sequential thread-local IDs into near-optimally spread
* multiplicative hash values for power-of-two-sized tables.
*/
private static final int HASH_INCREMENT = 0x61c88647; /**
* Returns the next hash code.
*/
private static int nextHashCode() {
return nextHashCode.getAndAdd(HASH_INCREMENT);
}
注意实例变量threadLocalHashCode, 每当创建ThreadLocal实例时这个值都会累加 0x61c88647, 目的在上面的注释中已经写的很清楚了：为了让哈希码能均匀的分布在2的N次方的数组里, 即 Entry[] table
下面来看一下ThreadLocal怎么使用的这个 threadLocalHashCode 哈希码的，下面是ThreadLocalMap静态内部类中的set方法的部分代码：
// Set the value associated with key.
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)]) {...} ...
key.threadLocalHashCode & (len-1)这么用是什么意思? 先看一下table数组的长度吧：
/**
* The table, resized as necessary.
* table.length MUST always be a power of two.
*/
private Entry[] table;
哇，ThreadLocalMap 中 Entry[] table 的大小必须是2的N次方呀(len = 2^N)，那 len-1 的二进制表示就是低位连续的N个1， 那 key.threadLocalHashCode & (len-1) 的值就是 threadLocalHashCode 的低N位, 这样就能均匀的产生均匀的分布? 我用python做个实验吧
>>> HASH_INCREMENT = 0x61c88647
>>> def magic_hash(n):
... for i in range(n):
... nextHashCode = i * HASH_INCREMENT + HASH_INCREMENT
... print nextHashCode & (n - 1),
...
>>> magic_hash(16)
7 14 5 12 3 10 1 8 15 6 13 4 11 2 9 0
>>> magic_hash(32)
7 14 21 28 3 10 17 24 31 6 13 20 27 2 9 16 23 30 5 12 19 26 1 8 15 22 29 4 11 18 25 0
产生的哈希码分布真的是很均匀，而且没有任何冲突啊, 太神奇了, javaspecialists中的一篇文章有对它的一些描述：
以及
这与fibonacci hashing(斐波那契散列法)以及黄金分割有关，具体可研究中的 6.4 节Hashing部分
4 线程池时使用 ThreadLocal
web容器(如tomcat)一般都是使用线程池处理用户到请求, 此时用ThreadLocal要特别注意内存泄漏的问题， 一个请求结束了，处理它的线程也结束，但此时这个线程并没有死掉，它只是归还到了线程池中，这时候应该清理掉属于它的ThreadLocal信息，
remove()
线程结束时应当调用ThreadLocal的这个方法清理掉thread-local变量
相关资料: