ThreadLocal源码阅读(一)

最近在阅读netty的源码，netty实现了自己的ThreadLocal (FastThreadLocal),因此打算系统了解下JDK中ThreadLocal的实现机制，并比较Netty和JDK的实现优劣；

JDK ThreadLocal

JDK的实现主要包括如下三个类:

1. Thread
2. ThreadLocal
3. ThreadLocal.ThreadLocalMap

Thread

Thread比较简单，只是定义了ThreadLocalMap类型的变量threadLocals,存储本线程中使用到的所有ThreadLocal及关联对象；

    ThreadLocal.ThreadLocalMap threadLocals = null;

ThreadLocalMap

ThreadLocalMap是一个内部类，从名字上猜测或许是一个Map,key是ThreadLocal,value是关联对象;实际上该类的确类似Map,但和我们经常使用的HashMap又有差异；
大家都知道HashMap的存储方式是Entry[]->链表，而ThreadLocalMap只是采用Entry[]，而不使用链表;那么ThreadLocal是如何解决hashcode冲突的呢？这部分代码在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) {//如果ThreadLocal为空,替换
                    replaceStaleEntry(key, value, i);
                    return;
                }
            }

            tab[i] = new Entry(key, value);
            int sz = ++size;
            if (!cleanSomeSlots(i, sz) && sz >= threshold)
                rehash();
        }

从上面的代码可以看到，set方法的逻辑如下：

1. 首先根据ThreadLocal元素的hashCode计算出其数组下标；
2. 由于是采用和len-1进行按位与操作，因此要求len是2的n次方，这样计算出来的结果应该是0~2^n-1；
3. 如果数组该下标并未存储内容，则将key和value组装为Entry ,存储到该下标中；另外需要判断是否进行扩容；
4. 如果该数组下标中已经存储了内容，则需要判断其Entry中的key和传入的ThreadLocal是否相同，如果相同，则更新Entry的value;如果Entry中的key为空，则说明ThreadLocal已经被垃圾回收(Entry是WeakReference类型，当垃圾回收时，如果没有其他的强引用，会被回收掉)，则调用replaceStaleEntry方法设值；否则继续判断数组的下一元素；

分析上面的源码发现，和HashMap的实现不一样，当对应的数组下标存在元素时，并不是通过链表的方式存储；而是在数组中寻找下一个可用的位置；因此当hash冲突加大时，set的效率会比较低；get方法也同样存在该问题；看到这，很好奇JDK是如何解决hash冲突问题的，问题的关键应该在ThreadLocal的hashcode上；

ThreadLocal

ThreadLoal中定义了int类型的threadLocalHashCode变量：

private final int threadLocalHashCode = nextHashCode();
    private static AtomicInteger nextHashCode =new AtomicInteger();
    private static final int HASH_INCREMENT = 0x61c88647;

   
    private static int nextHashCode() {
        return nextHashCode.getAndAdd(HASH_INCREMENT);
    }

可以看到其hashcode的生成规则为从0开始，每次递增0x61c88647；
为什么采用0x61c88647这个数字呢？

16进制	10进制	2进制
0x61c88647	1640531527	01100001110010001000011001000111 10011110001101110111100110111001(取反＋1)

10011110001101110111100110111001对应的10进制为2654435769；
在前文斐波那契散列法中讲到2654435769是一个斐波那契散列乘数，它的优点是通过它散列出来的结果分布会比较均匀，可以很大程度上避免hash冲突；
举例说明：
1.ThreadLocal的容量为16，threshold为16*2/3=10，那么计算的结果为：

序号	hashcode	数组下标
0	0x00	0
1	0x61c88647	7
2	0xc3910c8e	14
3	0x255992d5	5
4	0x8722191c	12
5	0xe8ea9f63	3
6	0x4ab325aa	10
7	0xac7babf1	1
8	0xe443238	8
9	0x700cb87f	15

2.ThreadLocal的容量为32，threshold为32*2/3=21，那么计算的结果为：

序号	hashcode	数组下标
0	0x00	0
1	0x61c88647	7
2	0xc3910c8e	14
3	0x255992d5	21
4	0x8722191c	28
5	0xe8ea9f63	3
6	0x4ab325aa	10
7	0xac7babf1	17
8	0xe443238	24
9	0x700cb87f	31
10	0xd1d53ec6	6
11	0x339dc50d	13
12	0x95664b54	20
13	0xf72ed19b	27
14	0x58f757e2	2
15	0xbabfde29	9
16	0x1c886470	16
17	0x7e50eab7	23
18	0xe01970fe	30
19	0x41e1f745	5
20	0xa3aa7d8c	12

可以看到，该算法计算出的数组下标分散性还是很好的；