Netty源码性能分析 - ThreadLocal PK FastThreadLocal

序

既然jdk已经有ThreadLocal，为何netty还要自己造个FastThreadLocal？FastThreadLocal快在哪里？这需要从jdk ThreadLocal的本身说起。在java线程中，每个线程都有一个ThreadLocalMap实例变量（如果不使用ThreadLocal，不会创建这个Map，一个线程第一次访问某个ThreadLocal变量时，才会创建）。该Map是使用线性探测的方式解决hash冲突的问题，如果没有找到空闲的slot，就不断往后尝试，直到找到一个空闲的位置，插入entry，这种方式在经常遇到hash冲突时，影响效率。

ThreadLocal 源码解析

在分析FastThreadLocal源码之前，先来分析ThreadLocal的源码。而分析ThreadLocal源码，在分析ThreadLocal源码之前，先来回顾一下ThreadLocal的使用。

ThreadLocal<Integer> threadLocal = new ThreadLocal<>();

threadLocal.set(1);

threadLocal.get();

threadLocal.remove();

上面是不是我们正常使用ThreadLocal方式，既然知道使用，那底层的原理是什么呢？先来看ThreadLocal<Integer> threadLocal = new ThreadLocal<>();这一行代码。

public ThreadLocal() {
}

遗憾的是，什么也没有做，就是普通的构造函数调用。接下来看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);
}

set()方法的原理也很简单，通过当前线程获取一个ThreadLocalMap对象，如果获取到了，则设置当前值，如果没有获取到 ThreadLocalMap，则创建ThreadLocalMap，并且设置ThreadLocalMap，但是这里需要注意一点，先来看ThreadLocalMap 的结构。在这里插入图片描述

结果发现，当调用set方法，实际上是创建了一个Entry对象，存储于ThreadLocalMap的Entry[] table数组中。

在这里插入图片描述
但是发现Entry继承了WeakReference类，这样做的用意是什么呢？Entry为什么要继承一个弱引用呢？网上有一篇博客 threadLocalMap 为啥用弱引用：为了让threadlocal的回收逻辑与使用该threadlocal的线程的回收逻辑相独立
在这里插入图片描述
ThreadLocal 举例来说可以作为一个对象中的引用，比如这个对象回收了，但线程是复用的（比如线程池）如果entry是强引用，就会引起threadlocal一直不回收。

为了防止类似情况发生，采用的弱引用。

有人说我平时都是用静态变量啊？如下
在这里插入图片描述
会将threadLocal变量声明为static的。但同样，我们也可以这样使用。

public static void main(String[] args) {
    for (int i = 0; i < 10; i++) {
        methodThreadLocal();
    }
}

public static void methodThreadLocal() {
    ThreadLocal<LargeObject> threadLocalLargeObject = new ThreadLocal<>();
	User user = new User();
    threadLocal.set(new LargeObject());

    threadLocal.get();
}

每次methodThreadLocal()方法调用都创建一个threadLocalLargeObject对象，每个线程中所有的ThreadLocal对象共用一下ThreadLocal.ThreadLocalMap，而在ThreadLocalMap中有一个Entry[] table属性，每个Entry对应一个ThreadLocal对象，Entry是一个key ，value 结构，key 存储了ThreadLocal对象，value存储了用户threadLocal.set(new LargeObject()) set 的业务值，这里value是 LargeObject 对象，在上例中当方法调用完，user 对象会被JVM回收掉，假如Entry的key（也就是ThreadLocal对象）属于强引用，而ThreadLocal.ThreadLocalMap是Thread对象的一个属性,它的生命周期和线程一样，而 Entry[] table又是ThreadLocalMap的属性，因此ThreadLocal.ThreadLocalMap.table.key(也就是ThreadLocal对象)一直是被强引用着，直到线程销毁，一直存在于内存中，对应的Entry对象在线程销毁前也一直不能被销毁，如果value是一个大对象，那么对象内存是一个极大的浪费，如果将 ThreadLocal 对象存储于弱引用对象中，那是什么样的情景呢？

先来看弱引用的定义和说明
【定义】

弱引用是使用WeakReference创建的引用，弱引用也是用来描述非必需对象的，它是比软引用更弱的引用类型。在发生GC时，只要发现弱引用，不管系统堆空间是否足够，都会将对象进行回收。

【说明】

弱引用，从名字来看就很弱嘛，这种引用指向的对象，一旦在GC时被扫描到，就逃脱不了被回收的命运。

在方法的内部，threadLocalLargeObject对象属于强引用，当方法调用结束，Entry中的key （也就是threadLocalLargeObject对象），Entry对它属于弱引用，因此随时可能被GC回收掉，而在后面ThreadLocal源码阅读中，时刻记住这一点，不然很多的代码感觉莫名其妙。

当然在实际开发中，静态变量会导致Threadlocal一直被强引用指着，ThreadlocalMap中的弱引用强引用并没有什么区别，刚刚提到的只有Threadlocal对象作为对象中的成员变量时，与线程做了分割。

接下来看ThreadLocal的set方法。

public void set(T value) {
    Thread t = Thread.currentThread();
    // 从当前线程中获取threadLocals对象，如果没有，则创建一个ThreadLocalMap对象
    ThreadLocalMap map = getMap(t);
    if (map != null)
        map.set(this, value);
    else
        createMap(t, value);
}

ThreadLocalMap getMap(Thread t) {
      return t.threadLocals;
}

上面代码也没有什么逻辑，如果当前线程ThreadLocalMap对象已经创建好，则直接返回，并调用其set()方法，如果ThreadLocalMap为空，则调用createMap()方法创建ThreadLocalMap对象。接下来看createMap()方法的实现。

void createMap(Thread t, T firstValue) {
    t.threadLocals = new ThreadLocalMap(this, firstValue);
}

ThreadLocalMap(ThreadLocal<?> firstKey, Object firstValue) {
	// INITIAL_CAPACITY的默认值为16
    table = new Entry[INITIAL_CAPACITY];
    int i = firstKey.threadLocalHashCode & (INITIAL_CAPACITY - 1);
    table[i] = new Entry(firstKey, firstValue);
    size = 1;
    setThreshold(INITIAL_CAPACITY);
}

private void setThreshold(int len) {
    threshold = len * 2 / 3;
}

上面这些代码，看上去简单，但有几点需要注意，首先创建了一个长度为16的Entry数组，其次firstKey.threadLocalHashCode & (16 - 1);是这一行代码，每个ThreadLocal变量都对应一个threadLocalHashCode哈希值，firstKey.threadLocalHashCode & 15的意思再明白不过了，也就是通过firstKey.threadLocalHashCode对15取余，从而计算ThreadLocal应该存储在table数组的索引值，这一点和HashMap很像。阅读过HashMap的源码肯定觉得threshold变量很熟悉，不就是负载因子嘛，比如HashMap的初始化长度为16，如果负载因子为0.8，则当HashMap的容量为(16*0.8=10)时，需要对HashMap进行扩容，这里的threshold值的含义也是一样，如table的初始化长度为16，threshold = (16 *2 ) /3 = 10 。当然这里仍然需要注意firstKey.threadLocalHashCode 的HashCode，还有其他隐藏的信息吗？
在这里插入图片描述
我们来做一个实验。

public class ThreadLocalTest2 {

    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);
    }


    public static void main(String[] args) {

        for (int i = 0; i < 35; i++) {
            ThreadLocalTest2 threadLocalTest2 = new ThreadLocalTest2();
            int b = threadLocalTest2.threadLocalHashCode;
            System.out.println(b & (16 - 1));
        }


    }
}

执行结果
在这里插入图片描述
大家发现规率没有，当数组长度为16时，计数出的数组索引值总是在下面这些值中循环。
0
7
14
5
12
3
10
1
8
15
6
13
4
11
2
9
而且table[16]的数组中，0~15的值没有出现重复，感兴趣的小伙伴可以将数组长度设置为32，则计算出的索引值也只会在0 ~ 31之间，并且不会重复，如果数组长度大于10时，则会进行数组扩容，如果我们定义的所有ThreadLocal都是static变量，则不会出现哈希冲突，但如果在方法中定义了ThreadLocal变量时，此时就会出现哈希冲突了。

public class ThreadLocal5 {

    public static void main(String[] args) throws Exception {

        ThreadLocal<LargeObject> threadLocal1 = new ThreadLocal<>();
        int threadLocal1HashCode = getFieldValue(threadLocal1);
        threadLocal1.set(new LargeObject());
        System.out.println("threadLocal1的索引值为：" + (threadLocal1HashCode & 15 ));
        for (int i = 0; i < 15; i++) {
            methodThreadLocal();
        }

        ThreadLocal<LargeObject> threadLocal2 = new ThreadLocal<>();
        int threadLocal2HashCode = getFieldValue(threadLocal2);

        System.out.println("threadLocal2的索引值为：" + (threadLocal2HashCode & 15 ));
    }


    public static void methodThreadLocal() {
        ThreadLocal<LargeObject> threadLocal = new ThreadLocal<>();
        threadLocal.set(new LargeObject());
        threadLocal.get();
    }

    public static int  getFieldValue(ThreadLocal threadLocal) throws Exception{
        Field field = ThreadLocal.class.getDeclaredField("threadLocalHashCode");
        field.setAccessible(true);
        return (int)field.get(threadLocal);


    }
}

结果输出threadLocal1和threadLocal2的索引值都为3 。

在这里插入图片描述
为什么索引值是3 ，而不是0呢？通过这一行代码threadLocal1.set(new LargeObject());打断点进入。

因此在线程启动运行到threadLocal1.set(new LargeObject());这一行代码时。 ThreadLocalMap的table对象中已经存储过

在这里插入图片描述
table[0],table[7],table[14],table[5],table[12]的对象了，只不过table[0],table[5],table[12]已经被gc回收掉了，上述代码比较麻烦，在代码中打断点和不打断点进行调试时，得出的结果不一样。因此重新写了一个例子。

public class ThreadLocal5 {


    public static void main(String[] args) throws Exception {
        ThreadLocal<LargeObject> threadLocal1 = new ThreadLocal<>();
        int threadLocal1HashCode = (int) getFieldValue(threadLocal1, "threadLocalHashCode");
        System.out.println("threadLocal1的索引值为：" + (threadLocal1HashCode & (getTableLength() -1 )));
        for (int i = 0; i < 15; i++) {
            methodThreadLocal();
        }
        ThreadLocal<LargeObject> threadLocal2 = new ThreadLocal<>();
        int threadLocal2HashCode = (int) getFieldValue(threadLocal2, "threadLocalHashCode");
        System.out.println("threadLocal2的索引值为：" + (threadLocal2HashCode & (getTableLength() -1 )));
    }

    public static int getTableLength() throws Exception{
        Object threadLocals = getFieldValue(Thread.currentThread(), "threadLocals");
        Object ob[] = (Object[]) getFieldValue(threadLocals, "table");
        System.out.println("ThreadLocalMap.table[]长度是" + ob.length);
        return ob.length;
    }

    public static void methodThreadLocal() {
        ThreadLocal<LargeObject> threadLocal = new ThreadLocal<>();
        threadLocal.set(new LargeObject());
        threadLocal.get();
        // 【注意】：模拟系统gc
        int threadLocal1HashCode = (int) getFieldValue(threadLocal, "threadLocalHashCode");
        Object threadLocals = getFieldValue(Thread.currentThread(), "threadLocals");
        Object ob[] = (Object[]) getFieldValue(threadLocals, "table");

        Object  entry= ob[threadLocal1HashCode & (ob.length-1)];

        Field field = entry.getClass().getSuperclass().getSuperclass().getDeclaredField("referent");
        field.setAccessible(true);
        field.set(entry,null);
    }

    public static Object getFieldValue(Object threadLocal, String fieldName) throws Exception {
        Field field = threadLocal.getClass().getDeclaredField(fieldName);
        field.setAccessible(true);
        return field.get(threadLocal);


    }
}

由于打断点，不打断点，机器本身的配置，JVM参数都会影响System.gc()，弱引用指向的对象也并不一定就马上会被回收，如果弱引用对象较大，直接进到了老年代，那么就可以苟且偷生到Full GC触发前，所以弱引用对象也可能存在较长的一段时间，因此测试比较麻烦，而系统gc的最终目的是，将Entry的referent属性回收掉，也就是调用Entry的get方法将返回null，因此使用加粗代码模拟System.gc()，通过获取ThreadLocal对象对应的Entry的referent值，将他设置为空，而JVM回收弱引用也是将referent设置为空，当ThreadLocal及时被JVM回收，table的length将不会超过负载因子10 ，因此就不会出现扩容，当第一个ThreadLocal对象的threadLocalHashCode & (16 -1 ) 和第17个ThreadLocal变量的threadLocalHashCode & (16 -1) 的值会相等，此时就会出现Hash值的冲突问题。
在这里插入图片描述
打印结果，ThreadLocal变量1和ThreadLocal变量2的threadLocal2的索引值为都为3，当然这些基础知识对于后面理解ThreadLocal源码有重要作用。接下来，继续看set()方法。

private void set(ThreadLocal<?> key, Object value) {

    // We don't use a fast path as with get() because it is at
    // least as common to use set() to create new entries as
    // it is to replace existing ones, in which case, a fast
    // path would fail more often than not.

    Entry[] tab = table;
    int len = tab.length;
    // 计算当前变量value应该存储在table[i]桶的位置
    int i = key.threadLocalHashCode & (len-1);

    for (Entry e = tab[i];
         e != null;
         // 每一次i = i ++ ，如果i > len -1  ,则i = 0 
         // 相当于循环遍历table[i]数组 
         e = tab[i = nextIndex(i, len)]) {
         // 如果table[i] 并不为空，会存在如下两种情况
        ThreadLocal<?> k = e.get();
		// 第一种情况
		// ThreadLocal threadLocal = new ThreadLocal<>();
        // threadLocal.set(1);
        // threadLocal.set(2);
        // 第二次对threadLocal变量赋值时，此时两次传入的ThreadLocal变量相等
        // 则直接用整形 2 覆盖掉 1 的值即可
        if (k == key) {
            e.value = value;
            return;
        }
		// 进入下面代码块会存在两种情况
		// 第一种情况，如i的值为3，当第17个ThreadLocal的计算出的索引值也为3 
		// ，当然table[]数组没有扩容，并且索引值 2~16 的table[i] 被JVM 回收的情况
		// 就会出现第1个和第17个ThreadLocal变量的哈希值都为3的情况
		// 此时假如 第一个ThreadLocal已经被JVM回收，k则为空
		
		// 第二种情况，当然table[]数组没有扩容，并且索引值 2~16 的table[i] 被JVM 回收的情况
		// 就会出现第1个和第17个ThreadLocal变量的哈希值都为3的情况
		// 假如第一个ThreadLocal变量并没有被JVM 回收，因为for 循环会查找下一个索引的
		// k 值，如果k为空 
        if (k == null) {
            replaceStaleEntry(key, value, i);
            return;
        }
    }
    
	// 如果table[i] == null ,则直接创建Entry对象，并填充table[i] 
    tab[i] = new Entry(key, value);
    int sz = ++size;
    // 如果并没有从table数组中扫描到entry的referent为空
    // 也就是说，并没有找到被JVM 回收的ThreadLocal，但此时数组的长度大于 
    // 等于负载因子threshold，则需要对table进行扩容处理 
    if (!cleanSomeSlots(i, sz) && sz >= threshold)
    	// 对table[]数组扩容
        rehash();
}

/**
 * Increment i modulo len.
 */
private static int nextIndex(int i, int len) {
    return ((i + 1 < len) ? i + 1 : 0);
}

/**
 * Decrement i modulo len.
 */
private static int prevIndex(int i, int len) {
    return ((i - 1 >= 0) ? i - 1 : len - 1);
}

先看下图。
在这里插入图片描述
我们看图理解set()方法中的for()循环代码，如果此时ThreadLocal的对应的索引值是3 ，则取出table[3]，如果table[3]为空，则直接table[3] = new Entry(key, value) ，如果此时table[i]不为空，则分两种情况，第一种情况table[i]的key值和当前ThreadLocal相等，当前ThreadLocal对象之前调用过set()方法并设置过值，此时直接将当前值覆盖掉之前的值即可，如果table[i]的key值和当前ThreadLocal又分为两种情况，第一种情况，table[i]的key值为空，table[i]的key值已经被JVM回收掉，第二种情况table[i]的key值不为空，外层for循环继续调用nextIndex(i, len) 方法查找下一个i，如 table[3].key != 当前ThreadLocal，则会查找table[4] ,table[5],table[6] … ，直到查找到table[i].key为空或table[i]为空为止，有人会说，万一查找完整个table[i]数组，都没有查找到满足table[i].key为空或者table[i]为空的条件会怎么办呢？这个你不用操心，每次向table数组中添加成功一个元素时，都会判断当前数组的长度大于 threshold 没有，而threshold 肯定小于 table.length的，因此无论何时，table[] 数组总有空闲的位置，大家有没有发现问题，如果table[3] 已经被占用用，会继续查找table[i]，直到table[i]或table[i].key为空，如果存在哈希值冲突比较多时，是不是插入和查找元素对性能带来影响。接下来看当table[i]的key为空时，则调用replaceStaleEntry()方法来处理。

private void replaceStaleEntry(ThreadLocal<?> key, Object value,
                               int staleSlot) {
    Entry[] tab = table;
    int len = tab.length;
    Entry e;

    // Back up to check for prior stale entry in current run.
    // We clean out whole runs at a time to avoid continual
    // incremental rehashing due to garbage collector freeing
    // up refs in bunches (i.e., whenever the collector runs).
    int slotToExpunge = staleSlot;
    for (int i = prevIndex(staleSlot, len);
         (e = tab[i]) != null;
         i = prevIndex(i, len))
        if (e.get() == null)
            slotToExpunge = i;

    // Find either the key or trailing null slot of run, whichever
    // occurs first
    for (int i = nextIndex(staleSlot, len);
         (e = tab[i]) != null;
         i = nextIndex(i, len)) {
        ThreadLocal<?> k = e.get();

        // If we find key, then we need to swap it
        // with the stale entry to maintain hash table order.
        // The newly stale slot, or any other stale slot
        // encountered above it, can then be sent to expungeStaleEntry
        // to remove or rehash all of the other entries in run.
        if (k == key) {
            e.value = value;

            tab[i] = tab[staleSlot];
            tab[staleSlot] = e;

            // Start expunge at preceding stale entry if it exists
            if (slotToExpunge == staleSlot)
                slotToExpunge = i;
            cleanSomeSlots(expungeStaleEntry(slotToExpunge), len);
            return;
        }

        // If we didn't find stale entry on backward scan, the
        // first stale entry seen while scanning for key is the
        // first still present in the run.
        if (k == null && slotToExpunge == staleSlot)
            slotToExpunge = i;
    }

    // If key not found, put new entry in stale slot
    tab[staleSlot].value = null;
    tab[staleSlot] = new Entry(key, value);

    // If there are any other stale entries in run, expunge them
    if (slotToExpunge != staleSlot)
        cleanSomeSlots(expungeStaleEntry(slotToExpunge), len);
}

一看上面代码，其实也是一头晕，什么东西，这么多，但你不用担心，我会一行一行代码给你解释，先来看这一段代码。

int slotToExpunge = staleSlot;
for (int i = prevIndex(staleSlot, len);
     (e = tab[i]) != null;
     i = prevIndex(i, len))
    if (e.get() == null)
        slotToExpunge = i;

还是看图说话。

在这里插入图片描述
如果table[3].key为空，此时向前查找会分几种情况。

如果table[2].key为空，则slotToExpunge = 2
如果table[2].key不为空，而table[1].key为空，则slotToExpunge = 1
如果table[2] 为空，即使table[1].key 为空，slotToExpunge = 3
如果table[2],table[1],table[0]都不有空，且key也不为空，但table[15]不为空，但table[15].key为空，则slotToExpunge = 15 。
如果table[2],table[1],table[0]都不有空，且key也不为空，但table[15]为空，则slotToExpunge = 3。
我相信通过上述举例，你应该对上述代码块理解了。所以table[slotToExpunge]不为空，且table[slotToExpunge].key 被JVM回收掉了。继续看后面的代码块。

接下来看下面这段代码块。

for (int i = nextIndex(staleSlot, len);
     (e = tab[i]) != null;
     i = nextIndex(i, len)) {
    ThreadLocal<?> k = e.get();
    if (k == key) {
        e.value = value;
        tab[i] = tab[staleSlot];
        tab[staleSlot] = e;
        
        if (slotToExpunge == staleSlot)
            slotToExpunge = i;
        cleanSomeSlots(expungeStaleEntry(slotToExpunge), len);
        return;
    }
    
    if (k == null && slotToExpunge == staleSlot)
        slotToExpunge = i;
}

依然是看图说话。
在这里插入图片描述
已知table[3]不为空，但table[3].key为空，如果table[4]不为空，但table[4].key为空，此时分两种情况。

如果从table[3]向前查找，查找到table[pre] 不为空，但table[pre].key为空的情况，此时slotToExpunge = pre 的值，slotToExpunge依然维持slotToExpunge = pre 。
像上面的第5种情况 5. 如果table[2],table[1],table[0]都不有空，且key也不为空，但table[15]为空，则slotToExpunge = 3，此时因为slotToExpunge = staleSlot = 3，而table[4].key为空，则slotToExpunge = 4 。

因此下面这段代码的意思是

... 
for (int i = nextIndex(staleSlot, len);
     (e = tab[i]) != null;
     i = nextIndex(i, len)) {
    ThreadLocal<?> k = e.get();
	...
    if (k == null && slotToExpunge == staleSlot)
        slotToExpunge = i;
}

如果从table[staleSlot]不为空，但table[staleSlot].key为空，如果向前查找，能查找到table[pre]不为空，但table[pre].key为空，则无论从table[staleSlot]向后查找的结果如何，slotToExpunge始终只会保存pre的值。但如果向前查找没有查找到符合条件的值，则向后查找，查找到第一个table[next] 不为空，且table[next].key为空，则slotToExpunge保存next的值，如table[4]，table[5]都不为空，而table[4].key和table[5].key都为空，则slotToExpunge始终等于4 。接下来理解下面这段代码。

for (int i = nextIndex(staleSlot, len);
     (e = tab[i]) != null;
     i = nextIndex(i, len)) {
    ThreadLocal<?> k = e.get();


    if (k == key) {
        e.value = value;

        tab[i] = tab[staleSlot];
        tab[staleSlot] = e;

        if (slotToExpunge == staleSlot)
            slotToExpunge = i;
        cleanSomeSlots(expungeStaleEntry(slotToExpunge), len);
        return;
    }

    ... 
}

如果向后查找过程中，查找到key 等于当前ThreadLocal对象，则交换位置。如下图所示
在这里插入图片描述
已知table[3]为空，而当前ThreadLocal计算的索引值为3，此时向后查找，如果table[5].key 等于当前ThreadLocal变量，此时将table[3]和table[5]的位置交换，如果此时slotToExpunge=3 ，则修改slotToExpunge=5。当然，如果向后查找过程中，直到table[next]为空了，依然没有查找到table[next].key值等于当前ThreadLocal时，则直接调用下面代码块即可。当然 tab[staleSlot].value 是help gc操作
tab[staleSlot].value = null;
tab[staleSlot] = new Entry(key, value);
从ThreadLocalMap的table 存储特性可以得知，如果存在hash冲突，如table[3].key不为空，此时计算出相同索引值为3的ThreadLocal只能向后查找，找到一个空位，则将当前ThreadLocal保存进去，当下一次再次来设置当前ThreadLocal的值时，table[3].key可能被JVM回收掉了，此时不能直接将table[3] = new Entry(当前ThreadLocal, value) ; 而是需要向后查找，看有没有table[next].key = 当前ThreadLocal的，如果有，则需要将table[next] 和当前table[3]的位置进行交换，这样也很好理解，如果当前ThreadLocal已经占用了其他槽位，而当前ThreadLocal计算出的槽位是table[3]，为了提升查找性能，需要将当前ThreadLocal存储于table[3]上，但存储之前，需要看之前有没有存储过当前ThreadLocal相关的数据，如果存储过，则需要将其清理掉，不然，table数组中存储的数据就会重复。当然，还需要考虑一个问题，为什么当查找到table[next] 为空时，依然没有查找到table[next].key 等于当前ThreadLocal时，就推断出table中肯定没有存储过当前ThreadLocal 相关的数据，就不再继续查找了呢？答案来源于expungeStaleEntry()方法，进入expungeStaleEntry方法的研究。

private int expungeStaleEntry(int staleSlot) {
    Entry[] tab = table;
    int len = tab.length;

    table[staleSlot].key为空，
    // 设置table[staleSlot].value为空，帮助gc，同时table存储元素的个数减1 
    tab[staleSlot].value = null;
    tab[staleSlot] = null;
    size--;
    
    Entry e;
    int i;
    for (i = nextIndex(staleSlot, len);
         (e = tab[i]) != null;
         i = nextIndex(i, len)) {
        ThreadLocal<?> k = e.get();
        if (k == null) {
            e.value = null;
            tab[i] = null;
            size--;
        } else {
            int h = k.threadLocalHashCode & (len - 1);
            if (h != i) {
                tab[i] = null;
                
                while (tab[h] != null)
                    h = nextIndex(h, len);
                tab[h] = e;
            }
        }
    }
    return i;
}

结合replaceStaleEntry()方法来看expungeStaleEntry()方法，在expungeStaleEntry方法中的staleSlot参数实际上是replaceStaleEntry()方法中的slotToExpunge变量，也就是说table[slotToExpunge]不为空，且table[slotToExpunge].key的值为空，已经被JVM回收掉了。
在这里插入图片描述
场景是这样子的，之前ThreadLocal1对象存储位置对于table[5]，而此时table[3].key已经被JVM回收为空，而table[4]不为空，但table[4].key为空，并且之前的table[3],table[4],table[5].table[6].table[7] 中ThreadLocal对应索引值都是3，只不过table[3],table[4].key已经被回收了，当然table[8]为空，而在replaceStaleEntry()方法中，已经将table[3]和table[5]交换，假设table[3]之前的元素中并没有table[pre].key为空的情况，因此slotToExpunge=4，此时再来理解expungeStaleEntry()方法，首先将table[4]的value值设置为空，再将table[4]=null,并且数组中存储元素size - 1 ，因为在replaceStaleEntry()方法中table[5]只是和table[3]交换位置，并没有将table[5]置空，因此table[5]会走下面红框代码逻辑
在这里插入图片描述
此时再次遍历table[6] ，而table[3]已经被当前ThreadLocal占用，但table[4]和table[5] 已经被置空，而table[6]会走下面红框代码。

先查找table[3]有没有被占用，如果被占用，再查找table[4]有没有被占用，在前面已经将table[4]置空了，此时table[4] = table[6],并且将table[6] 置空，而i继续++，因为table[5]已经被
e.value = null;
tab[i] = null;
size–;
这段代码置空了，因此table[7]又会走table[6]地老路，table[5]=table[7]，table[7] = null,而table[8]本身为空，则退出循环,返回i = 7 ，通过expungeStaleEntry()方法的调用，最终table[3],table[4],tab[5]被填充，table[6],table[7]被置空，大家发现没有，每一次expungeStaleEntry()方法调用，都会将table[next]放到其对应的索引位置i，或者table[i]后面的元素，如table[3] ，table[4],table[5] 对应的索引都为3，table[6]为空，table[3] 不为空，table[4]的key为空，table[5]的key不为空，经过expungeStaleEntry()方法调用后，不可能出现table[3]不为空，table[4] 为空，table[5]不为空的情况，只会是table[3] 依然是原来的table[3] ， table[4] = table[5] ,table[5] 为空，expungeStaleEntry()方法的目的是将table压紧实一点。为什么从ThreadLocal Hash码对应的索引值向后查找，只要查找到table[next]为空还没有查找key为ThreadLocal的变量，则证明 table中没有存储过ThreadLocal对应的Entry呢？搜索ThreadLocal源码，发现只有expungeStaleEntry()方法中
在这里插入图片描述
才会将table[i] 置空，调用threadLocal的remove()方法，也只是将table[i].key置空，真正的将table[i]置空的代码还是在expungeStaleEntry()方法中，而expungeStaleEntry()方法不仅有将table压紧实的功能，还有重置table[i]位置的功能，具体代码在如下代码。

int h = k.threadLocalHashCode & (len - 1);
if (h != i) {
    tab[i] = null;
    
    while (tab[h] != null)
        h = nextIndex(h, len);
    tab[h] = e;
}

当k不为空，则通过k.threadLocalHashCode & (len - 1);计算出ThreadLocal应该的索引值 h ，计算出的索引值和当前 ThreadLocal 存储的索引值不相等，则从 h向后一个一个查找，如果不幸运的话，依然可能ThreadLocal还是放回到原来的位置。依然是看图说话。
在这里插入图片描述
当table[2].key 为空，table[3]的索引值为3，table[4]的索引值为4，table[4]的索引值为5 ，table[6]的索引值为3 ，则expungeStaleEntry()方法中，table[2] 被置空，当 table[6]计算出索引值为3，但table[4],table[4],table[5]都不为空，因此table[6] 依然还是放回到原来的位置。

好像还是没有说明白，为什么从ThreadLocal Hash码对应的索引值向后查找，只要查找到table[next]为空还没有查找key为ThreadLocal的变量，则证明 table中没有存储过ThreadLocal对应的Entry对象？那我们从另外一个理论上来分析。
在这里插入图片描述
比如当前ThreadLocal计算出索引值为3，如果当前ThreadLocal 存储在table[3]这个位置，第一次通过k.threadLocalHashCode & (len - 1) = 3 计算索引，就能立刻查找到它，但当前ThreadLocal 不存储在table[3]，那么只可能存储在table[4] … 之后的位置，假如存储的位置为table[i]，ThreadLocal.set()方法的特性就决定了 3 ~ i之间的table元素肯定不为空，当3 ~i 之间的元素需要置空时，则会调用expungeStaleEntry()方法，而expungeStaleEntry()方法中的for循环肯定会遍历3 ~ i 元素，甚至是i 之后的元素，因为for循环的条件就是，

for (i = nextIndex(staleSlot, len);
                 (e = tab[i]) != null;
                 i = nextIndex(i, len))

e[i]不等于空时，将一直循环下去，因此当 i 将被下面

int h = k.threadLocalHashCode & (len - 1);
if (h != i) {
    tab[i] = null;
    
    while (tab[h] != null)
        h = nextIndex(h, len);
    tab[h] = e;
}

这段代码处理，如果 table[3]为空，并且3 ~i 之间没有索引值为3的ThreadLocal，table[3]将被table[i] 替换，如果table[3] 不为空，此时会从索引值为3向后遍历，直到找到一个空位为止，假如是 j ，那么3 ~ j 之间的元素肯定都不为空，因此在查找时，只要table[next] == null 时依然没有查找到当前ThreadLocal对应的Entry，则证明table中没有存储当前ThreadLocal对应的Entry。我相信现在你总对expungeStaleEntry()方法理解了吧。接下来看cleanSomeSlots()方法。

private boolean cleanSomeSlots(int i, int n) {
    boolean removed = false;
    Entry[] tab = table;
    int len = tab.length;
    do {
        i = nextIndex(i, len);
        Entry e = tab[i];
        if (e != null && e.get() == null) {
            n = len;
            removed = true;
            i = expungeStaleEntry(i);
        }
    } while ( (n >>>= 1) != 0);
    return removed;
}

其实cleanSomeSlots()这个方法可以用佛系的思维来理解，首先table[i]肯定为空，看cleanSomeSlots()方法有三个地方调用，
在这里插入图片描述

在expungeStaleEntry()方法返回值i , table[i]肯定为空，而set()方法中，table[i] 等于新插入的值，在cleanSomeSlots()方法中，table[i]是不能动的。先来模拟测试一下cleanSomeSlots()方法。

假如table 数组的长度为16，默认情况下，如果table[i + 1] ,table[i + 2 ] ,table[i + 3 ] ,table[i + 4 ] ,table[ i + 5 ] 没有key 为空的元素，则退出循环， i + 1 ~ i + 5 之间有任意一个元素的key值为null，则会调用expungeStaleEntry()方法，开始清理元素，假如table [i + 1 ] ~ table[ i + 5] 之间的元素中，table[i + 4] 为空， table[i+6] 不为空，table[i + 7] 为空，此时调用expungeStaleEntry()方法，将table[i+4]设置为空，假如table[i +5] 和table[i +6] 的ThreadLocal HashCode的索引值和table[i + 4]相同，则table[i + 4] 将被table[i + 5]或table[i + 6] 覆盖掉，此时table[i + 7] 为空，则此时expungeStaleEntry()方法将返回i + 7，因此在cleanSomeSlots方法中i = i + 7 ,并且设置remove为true，这个有什么用呢？在set()方法中，如果向table中添加了元素，此时调用cleanSomeSlots()方法返回true，则证明移除元素成功，则不需要进行扩容判断，如果调用expungeStaleEntry方法返回 i = i + 7 ,则此时在cleanSomeSlots()方法while循环判断table[i + 8 ] ~ table[ i + 12 ] 有没有元素的key值为空，重复上面i + 1的操作，当然称它比较佛系，是因为从i + 1 开始查找，如果查找log2(table.length)次都没有找到key为空的元素，则放弃查找。假如table[i + 1 ] ~ table[i + 5] 的key都不为空，但table[i +6] 的key值为空，而此时刚好table中存储的元素个数大于等于 10，即使table[i +6]的key为空，也会导致table扩容。既然这里涉及到table[]扩容处理，接下来分析table[]扩容代码。 rehash()函数实现。

private void rehash() {
    expungeStaleEntries();
    // 如果当前table的元素个数大于等于 threshold - threshold / 4，则重新进行hash值的计算 
    if (size >= threshold - threshold / 4)
        resize();
}

先调用expungeStaleEntries()函数，如果此时size的值仍然大于threshold - threshold / 4，则对数组进行扩容，先来看expungeStaleEntries()代码，再来分析扩容机制。

private void expungeStaleEntries() {
    Entry[] tab = table;
    int len = tab.length;
    for (int j = 0; j < len; j++) {
        Entry e = tab[j];
        if (e != null && e.get() == null)
            expungeStaleEntry(j);
    }
}

上面这段代码的理解很简单，就是遍历整个table数组，将table[i].key为空的table[i]元素置空掉。再结合rehash()函数来看，如果清空掉所有的table[i].key为空的元素之后，此时数组的长度仍然大于等于threshold - threshold / 4，则对数组进行扩容，这里需要注意一点，假如数组长度为16，则threshold = 16 * 2 / 3 = 10 ，而当 10 - 10/4 = 8 ,这下好理解了，当table中元素个数大于等于10个时，此时会触发rehash，而rehash方法中，先遍历整个table数组，清除掉table[i].key为空的元素，也就是ThreadLocal已经被JVM回收的Entry元素，此时若剩下的元素个数仍然大于等于8，则需要对table数组扩容了。接下来看table数组的扩容逻辑。

private void resize() {
    Entry[] oldTab = table;
    int oldLen = oldTab.length;
    int newLen = oldLen * 2;
    // 数组长度扩容为原来的两倍
    Entry[] newTab = new Entry[newLen];
    int count = 0;

    for (int j = 0; j < oldLen; ++j) {
        Entry e = oldTab[j];
        if (e != null) {
            ThreadLocal<?> k = e.get();
            // 如果扩容过程中，table[j].key已经被JVM回收了
            // 先将e.value设置为空，有助于GC 
            if (k == null) {
                e.value = null; // Help the GC
            } else {
            	// 重新计算table[j]的ThreadLocal的hash值对应的索引
                int h = k.threadLocalHashCode & (newLen - 1);
                // 如果索引位置已经存储了其他元素，则h ++
                // 直到table[h+i] == null为止，此时k对应Entry 存储于table[h+i]中 
                while (newTab[h] != null)
                    h = nextIndex(h, newLen);
                newTab[h] = e;
                // 记录table[]数组中存储的元素个数
                count++;
            }
        }
    }
	// 重新设置负载因子 
    setThreshold(newLen);
    size = count;
    table = newTab;
}

resize()方法的逻辑也很简单，但需要注意的时，在进行数组拷贝时，仍然有table[j].key被jvm回收的可能，其他的就容易了，因为数组的长度变为原来的两倍，当然每个元素的key对应在table中的索引也需要重新计算，计算出来的索引所在位置如果已经被其他元素占用，依次向后查找，直到找到空位，将table[j]放入进去。当然在最后，就是重新设置负载因子，数组中存储的有效元素个数，以及用新的table替换掉原来的table。当然有人会想，这样扩容，会不会存在并发问题，聪明的读者肯定想到了，在同一个线程中，假如ThreadLocal1.set()方法触发扩容，即使此时调用ThreadLocal2.set()方法，也需要当ThreadLocal1.set()方法调用完后，才会触发ThreadLocal2.set()调用，因为ThreadLocal相关的所有操作都在同一个线程中执行，因此上述扩容不存在并发问题。
接下来看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) {
            @SuppressWarnings("unchecked")
            T result = (T)e.value;
            return result;
        }
    }
    return setInitialValue();
}

当ThreadLocalMap不存在时，此时会调用setInitialValue()方法初始化ThreadLocalMap，

private T setInitialValue() {
    T value = initialValue();
    Thread t = Thread.currentThread();
    ThreadLocalMap map = getMap(t);
    if (map != null)
        map.set(this, value);
    else
        createMap(t, value);
    return value;
}

protected T initialValue() {
    return null;
}

setInitialValue()方法和set()方法很相似，调用setInitialValue()方法的好处是什么呢？虽然初始化当前ThreadLocal的value值为null，但提前调用get()方法，能使得当前ThreadLocal先去table数组中占领一个槽位，当下次再使用时，能尽快的查找到当前ThreadLocal所对应的槽位，一定程度上提升了当前ThreadLocal的使用速度。当然如果已经存在了ThreadLocalMap，则会调用其getEntry()获取Entry，如果Entry对象不为空，则返回Entry的value值。接下来进入getEntry()方法的阅读。

private Entry getEntry(ThreadLocal<?> key) {
    int i = key.threadLocalHashCode & (table.length - 1);
    Entry e = table[i];
    if (e != null && e.get() == key)
        return e;
    else
        return getEntryAfterMiss(key, i, e);
}

这里分为两种情况，先通过ThreadLocal的threadLocalHashCode值计算出在table数组中的位置，如果table[i].get() == 当前ThreadLocal，则直接返回table[i]对应的Entry即可，但如果table[i]被其他的ThreadLocal占用了，此时需要调用getEntryAfterMiss()方法进一步查找当前ThreadLocal对应的Entry。在之前的源码中知道，在调用set()方法时，如果table[i]被其他元素占用，则会从table[i+1]开始向后查找，直到找到一个空位table[i +j]为止，再将当前ThreadLocal封装成Entry存储于空位的table[i +j]中。我们来看第二种情况。

private Entry getEntryAfterMiss(ThreadLocal<?> key, int i, Entry e) {
    Entry[] tab = table;
    int len = tab.length;

    while (e != null) {
        ThreadLocal<?> k = e.get();
        if (k == key)
            return e;
        if (k == null)
            expungeStaleEntry(i);
        else
            i = nextIndex(i, len);
        e = tab[i];
    }
    return null;
}

上述代码中也很好理解，从 i 开始向后查找，如果table[i].key的值等于当前线程，则说明找到了对应的Entry了，如果table[i + j ] == null 还没有找到有key值和当前ThreadLocal相等的Entry，说明此table中没有存储ThreadLocal对应的Entry，如果从table[i]向后查找过程中，发现table中的元素key值为空，说明此元素可以被清理，因此会调用expungeStaleEntry()方法清除被JVM回收的元素。虽然上述代码看上去简单，但依然有两处代码暗藏杀机。

为什么在getEntry()方法中已经判断过e == null || e.get() != key ，才会调用getEntryAfterMiss()方法，e == null 调用getEntryAfterMiss()方法很好理解，直接返回null即可，根本不会进入while()循环，但e !=null && e.get() != key 时调用getEntryAfterMiss()方法，此时i 为什么不从 i + 1 开始判断，在getEntry()方法中已经确定了e !=null && e.get() != key ，在while()循环内部还进行 if (k == key) 判断不是多此一举吗？聪明的读者肯定看到了if (k == null) 这一行代码，显然对于 e !=null && e.get() != key 这种情况，k == key 一定为false，但会进入到if (k == null) 这一行的判断，因为在getEntry()方法中判断时， e.get() 是不为空的，但在getEntryAfterMiss()方法调用时，e.get()可能就被JVM回收掉了，所以存在e.get()==null的情况，如果e.get()==null ，则将table[i] 对应的e 置空掉，所以在getEntryAfterMiss()方法中对table[i]的处理并不是多此一举，一定程序上优化程序的性能，节省内存空间。
另外一个疑问，在expungeStaleEntry(i) 调用时，此时 i 并没有 + 1 ，为什么呢？而是当expungeStaleEntry(i);调用完成时，依然从获取table[i]的值进行判断，之前阅读expungeStaleEntry(i)的源码时就已经知道，expungeStaleEntry()方法有两个功能，第一，压缩清理table[i]，第二，重置table中元素的索引。还是以之前的例子来分析，假如table[3],table[4],table[5] ,table[6]4个元素，table[3],的索引为3，table[4]的索引为4，table[5]的索引为3，table[6]为空值，当前ThreadLocal对应的Entry存储于table[5]，但此时table[3].key被JVM回收掉，此时i = 3 ,调用expungeStaleEntry()方法，expungeStaleEntry()方法的内部，先将table[3] 置空，此时会向后查找到table[4],而table[4]的索引为4，依然将table[4]放在原来的位置，此时table[5]就是当前ThreadLocal对应的元素，并且table[5]对应的索引为3，此时会将table[3] = table[5], table[5]置空，因此在调用完expungeStaleEntry()方法后，table[3] 中存储了当前ThreadLocal对应的Entry，因此当发现i 的key为空时，调用expungeStaleEntry(i) 方法后，查找位置依然只能从i 开始，不能从i +1 开始，在expungeStaleEntry()方法的处理过程中，可能会将i 后面的元素移动到table[i]上来，如果i + 1 ，则会漏掉table[i]元素的比对。

虽然get()方法看上去简单，但是也暗藏着上述两处细节，希望细心的读者能够发现。

接下来看ThreadLocal的remove()方法。

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;
        }
    }
}

public void clear() {
    this.referent = null;
}

remove()方法的原理就很简单了，先通过 key.threadLocalHashCode计算出key对应在table中的位置，然后从 i 开始向后逐个查找，如果查找到当前ThreadLocal对应的Entry元素，则将Entry的key设置为空，再调用expungeStaleEntry()方法，清理，压缩，移动元素。

ThreadLocal源码总结：

有人说ThreadLocal性能真心差，但我觉得ThreadLocal的设计还是有很多值得学习的地方，也为我们考虑了很多，ThreadLocal性能真心差吗？不好说，如果项目中都是使用全局static变量来使用ThreadLocal，则不可能存在hash冲突，性能无与伦比，当大量在方法内部使用ThreadLocal时，这种情况可能就会出现hash冲突，但每次在set，get()元素的过程中，都会存在重置ThreadLocal的位置可能，在设置和查找过程中，性能真的那么差吗？也不好说，只是在极端情况下，才会出现比较多的依次查找的情况，当然FastThreadLocal 是后面开发和设计的，它肯定是发现了ThreadLocal可能存在的风险，从而规避了这些性能差的风险，真正意义上的达到完美。接下来将分析 FastThreadLocal源码。

在研究FastThreadLocal源码之前，依然是看一个例子。

public class FastThreadLocalTest2 {

    public static void main(String[] args) {
        final FastThreadLocal<String> threadLocal = new FastThreadLocal<String>();
        threadLocal.set("1");

        System.out.println(threadLocal.get());
        threadLocal.remove();
        
        FastThreadLocal.removeAll();
    }
}

从这个例子中，依然关注4个方法，FastThreadLocal()的构造方法，set()方法，get()方法， remove()方法，removeAll()方法。
先来看FastThreadLocal的构造函数。

private static final int variablesToRemoveIndex = InternalThreadLocalMap.nextVariableIndex();

private final int index;

public FastThreadLocal() {
    index = InternalThreadLocalMap.nextVariableIndex();
}

这里引用了InternalThreadLocalMap的nextVariableIndex()方法，接下来看nextVariableIndex()方法。

public static int nextVariableIndex() {
    int index = nextIndex.getAndIncrement();
    if (index < 0) {
        nextIndex.decrementAndGet();
        throw new IllegalStateException("too many thread-local indexed variables");
    }
    return index;
}

这里又用到了一个变量nextIndex，而nextIndex变量又是InternalThreadLocalMap类的父类，他们之间的关系是父子关系。
在这里插入图片描述
先来看一下UnpaddedInternalThreadLocalMap的类结构。

从UnpaddedInternalThreadLocalMap的类结构中可以看出nextIndex是一个静态final变量，当然还有ThreadLocal<InternalThreadLocalMap> slowThreadLocalMap这个变量也值得注意，存储数据的数组当然是Object[] indexedVariables，当然slowThreadLocalMap，nextIndex，indexedVariables 这三个变量有什么用呢？根据FastThreadLocal的源码来分析nextIndex变量。在FastThreadLocal的构造函数中，初始化了一个变量index，并且index 的值声明为了final类型，因此每个FastThreadLocal都有唯一一个index与之对应。同时FastThreadLocal中也有一个variablesToRemoveIndex变量，这个变量也是值得注意的。这个变量被声明为private static final int variablesToRemoveIndex = InternalThreadLocalMap.nextVariableIndex();
同样variablesToRemoveIndex也属于一个索引值，这个索引值位置的存储了一个 Set<FastThreadLocal<?>>集合，而这个Set集合中的元素也就是InternalThreadLocalMap的indexedVariables数组中存储的元素。

在这里插入图片描述
看图说话，在整个程序启动过程中，第一次创建FastThreadLocal会初始化variablesToRemoveIndex变量，一般情况下variablesToRemoveIndex的值为0。而indexedVariables[variablesToRemoveIndex] 这个位置存储了一个Set<FastThreadLocal<?>>集合，在后面源码阅读的过程中，你会发现他是Collections.SetFromMap对象。看一下其结构，后面使用到再来分析。
在这里插入图片描述

在整个JVM 运行过程中，每创建一个FastThreadLocal对象，FastThreadLocal的index属性值就会加1，因此每个FastThreadLocal都有唯一一个index与之对应，这就带来另外一个问题，如上图中线程1 创建的3个FastThreadLocal，其索引值分别是1，4，5 ，而线程2创建的4个FastThreadLocal对应的索引值分别是2，3，6，7。不同的线程创建的FastThreadLocal的索引值不会重复。当然啦，如果index的值大于Integer.MAX_VALUE时，会抛出异常，就是JVM 整个运行中，创建FastThreadLocal对象个数大于 Integer.MAX_VALUE，再次创建FastThreadLocal时，将抛出too many thread-local indexed variables 异常。

public static int nextVariableIndex() {
    int index = nextIndex.getAndIncrement();
    if (index < 0) {
        nextIndex.decrementAndGet();
        throw new IllegalStateException("too many thread-local indexed variables");
    }
    return index;
}

因为index的值是不能重复的，而每个线程中存储FastThreadLocal数据是一个数组，也就是UnpaddedInternalThreadLocalMap中的indexedVariables属性，而数组是需要提前申请内存空间的，如上图中，因为2，3，6，7槽位被线程2占用了，因此线程1只能将它填充为一个Object 对象的引用，从而来达到节省内存空间，虽然空间的浪费，但换来了性能的提升，任何get(),set()操作都只需indexedVariables[index]就能定位到FastThreadLocal。查找虽然方便了，如果没有 Set<FastThreadLocal<?>> 保存FastThreadLocal的引用，在清理indexedVariables就变得异常麻烦，只能遍历整个indexedVariables数组，显然这样操作性能低下，也是 Netty 所不能容忍的，因此每个线程创建了一个Set<FastThreadLocal<?>> 集合来存储线程中所有FastThreadLocal的引用，当需要removeAll()时，只需要从Set<FastThreadLocal<?>> 中取出FastThreadLocal对象，再从FastThreadLocal对象中取出索引值index，再清除掉indexedVariables[index] 即可。先来看两个例子，证实上面的代码。

variablesToRemoveIndex 并不一定是从0开始的，而是在整个JVM运行中，第一次创建FastThreadLocal对象初始化variablesToRemoveIndex变量，先看一个测试用例。

public class FastThreadLocalTest4 {

    public static void main(String[] args) throws Exception {
        InternalThreadLocalMap.nextVariableIndex();
        InternalThreadLocalMap.nextVariableIndex();
        InternalThreadLocalMap.nextVariableIndex();
        InternalThreadLocalMap.nextVariableIndex();

        FastThreadLocal fastThreadLocal = new FastThreadLocal();

        System.out.println("variablesToRemoveIndex = "+getFieldValue(fastThreadLocal , "variablesToRemoveIndex"));

        fastThreadLocal.set(10);

        System.out.println("index = " + getFieldValue(fastThreadLocal , "index"));
    }
    
    public static Object getFieldValue(Object threadLocal, String fieldName) {
        try {
            Field field = threadLocal.getClass().getDeclaredField(fieldName);
            field.setAccessible(true);
            return field.get(threadLocal);
        } catch (NoSuchFieldException e) {
            e.printStackTrace();
        } catch (SecurityException e) {
            e.printStackTrace();
        } catch (IllegalArgumentException e) {
            e.printStackTrace();
        } catch (IllegalAccessException e) {
            e.printStackTrace();
        }

        return null;

    }
}

结果输出：
variablesToRemoveIndex = 4
index = 5

分析，每一次InternalThreadLocalMap.nextVariableIndex()调用，都会触使UnpaddedInternalThreadLocalMap的nextIndex ++，因此在前面4次调用nextVariableIndex()方法，0，1，2，3 已经被占用，当new FastThreadLocal()时，此时variablesToRemoveIndex的值被第一次初始化，因此值为4，而FastThreadLocal本身的索引值也就是5了。

接下来看另外一个例子，如果索引值被其他线程占用了，那些占用的索引位置真的只能填充Object()对象的引用吗？不能使用吗？答案是肯定的。再来看一个例子。

public class FastThreadLocalTest3 {
    public static void main(String[] args) {
        for (int i = 0; i < 10; i++) {
            new Thread(new Runnable() {
                @Override
                public void run() {
                    FastThreadLocal fastThreadLocal0 = new FastThreadLocal();
                    System.out.println(Thread.currentThread().getName() + ":" + getFieldValue(fastThreadLocal0, "variablesToRemoveIndex"));
                    fastThreadLocal0.set(10);
                    System.out.println(Thread.currentThread().getName() + ":" + getFieldValue(fastThreadLocal0, "index"));


                    FastThreadLocal fastThreadLocal2 = new FastThreadLocal();
                    System.out.println(Thread.currentThread().getName() + ":" + getFieldValue(fastThreadLocal2, "variablesToRemoveIndex"));
                    fastThreadLocal2.set(20);
                    System.out.println(Thread.currentThread().getName() + ":" + getFieldValue(fastThreadLocal2, "index"));


                    FastThreadLocal fastThreadLocal3 = new FastThreadLocal();
                    System.out.println(Thread.currentThread().getName() + ":" + getFieldValue(fastThreadLocal3, "variablesToRemoveIndex"));
                    fastThreadLocal3.set(20);
                    System.out.println(Thread.currentThread().getName() + ":" + getFieldValue(fastThreadLocal3, "index"));


                    FastThreadLocal fastThreadLocal4 = new FastThreadLocal();
                    System.out.println(Thread.currentThread().getName() + ":" + getFieldValue(fastThreadLocal4, "variablesToRemoveIndex"));
                    fastThreadLocal4.set(20);
                    System.out.println(Thread.currentThread().getName() + ":" + getFieldValue(fastThreadLocal4, "index"));

                }
            }).start();
        }
        try {
            Thread.sleep(1000);

            FastThreadLocal fastThreadLocal = new FastThreadLocal();

            System.out.println(Thread.currentThread().getName() + ":" + getFieldValue(fastThreadLocal, "variablesToRemoveIndex"));

            fastThreadLocal.set(10);

            System.out.println("========" + Thread.currentThread().getName() + ":" + getFieldValue(fastThreadLocal, "index"));
            InternalThreadLocalMap internalThreadLocalMap = InternalThreadLocalMap.get();
            Field field = InternalThreadLocalMap.class.getSuperclass().getDeclaredField("indexedVariables");
            field.setAccessible(true);
            Object[] indexedVariables = (Object[]) field.get(internalThreadLocalMap);
            System.out.println(indexedVariables);
        } catch (Exception e) {
            e.printStackTrace();
        }
    }

    public static Object getFieldValue(Object threadLocal, String fieldName) {
        try {
            Field field = threadLocal.getClass().getDeclaredField(fieldName);
            field.setAccessible(true);
            return field.get(threadLocal);
        } catch (NoSuchFieldException e) {
            e.printStackTrace();
        } catch (SecurityException e) {
            e.printStackTrace();
        } catch (IllegalArgumentException e) {
            e.printStackTrace();
        } catch (IllegalAccessException e) {
            e.printStackTrace();
        }
        return null;
    }
}

在前面创建了10个线程，每个线程都创建了4个FastThreadLocal，因为第0个位置被Set<FastThreadLocal<?>>占用，因此前面10个线程总共占有的索引应该是0~40，当主线程睡眠1秒后，他所能分到的索引值是41
在这里插入图片描述
再来看，真的indexedVariables数组前面40个槽位是空闲的吗？

从演示效果上来看，确实如我们猜想的那样。

接下来继续看FastThreadLocal的set()方法。

public final void set(V value) {
    if (value != InternalThreadLocalMap.UNSET) {
        InternalThreadLocalMap threadLocalMap = InternalThreadLocalMap.get();
        setKnownNotUnset(threadLocalMap, value);
    } else {
    	// 传入的值为InternalThreadLocalMap.UNSET，相当于FastThreadLocal.remove() 方法调用
        remove();
    }
}

在set()方法调用过程中分两种情况，每一种，当设置的value值为InternalThreadLocalMap.UNSET，第二种，当设置的value值不是InternalThreadLocalMap.UNSET时。因此，先来看value == InternalThreadLocalMap.UNSET 的情况。先来看 InternalThreadLocalMap.get()这一行代码。

public static InternalThreadLocalMap get() {
    Thread thread = Thread.currentThread();
    // 如果thread是FastThreadLocalThread 
    if (thread instanceof FastThreadLocalThread) {
        return fastGet((FastThreadLocalThread) thread);
    } else {
        return slowGet();
    }
}
private static InternalThreadLocalMap fastGet(FastThreadLocalThread thread) {
    InternalThreadLocalMap threadLocalMap = thread.threadLocalMap();
    if (threadLocalMap == null) {
        thread.setThreadLocalMap(threadLocalMap = new InternalThreadLocalMap());
    }
    return threadLocalMap;
}

从上述代码来看，获取InternalThreadLocalMap分两种情况，如果获取到的InternalThreadLocalMap为空，则会调用new InternalThreadLocalMap()初始化threadLocalMap，当然，一个线程只有一个threadLocalMap。 InternalThreadLocalMap没有什么特殊的属性，因此在后面的分析过程中，再来分析具体的方法，已知的InternalThreadLocalMap继承UnpaddedInternalThreadLocalMap类，并且拥有Object[] indexedVariables 属性，实际上线程中的所有FastThreadLocal都存储于这个属性中。接着继续看set()方法，InternalThreadLocalMap.get()方法调用，一定会返回一个InternalThreadLocalMap对象。再调用setKnownNotUnset()方法处理，那setKnownNotUnset()这个方法做了哪些事情呢？

private void setKnownNotUnset(InternalThreadLocalMap threadLocalMap, V value) {
    if (threadLocalMap.setIndexedVariable(index, value)) {
        addToVariablesToRemove(threadLocalMap, this);
    }
}

当然设置value的过程中分为两步，第一步将value保存到InternalThreadLocalMap的indexedVariables变量中，第二步，将新创建的FastThreadLocal记录到Set<FastThreadLocal<?>> ，方便后面removeAll() 方法移除线程中所有的FastThreadLocal，先看setIndexedVariable()方法实现。

public boolean setIndexedVariable(int index, Object value) {
    Object[] lookup = indexedVariables;
    if (index < lookup.length) {
        Object oldValue = lookup[index];
        lookup[index] = value;
        return oldValue == UNSET;
    } else {
        expandIndexedVariableTableAndSet(index, value);
        return true;
    }
}

当然setIndexedVariable()又分为两种情况，如果当前索引值小于 indexedVariables数组长度，则直接将value覆盖掉indexedVariables[index]位置的值即可，如果index的值大于indexedVariables的长度时，则需要对数组进行扩容，接下来看indexedVariables扩容处理。

private void expandIndexedVariableTableAndSet(int index, Object value) {
    Object[] oldArray = indexedVariables;
    final int oldCapacity = oldArray.length;
    int newCapacity = index;
    newCapacity |= newCapacity >>>  1;
    newCapacity |= newCapacity >>>  2;
    newCapacity |= newCapacity >>>  4;
    newCapacity |= newCapacity >>>  8;
    newCapacity |= newCapacity >>> 16;
    newCapacity ++;
    
    Object[] newArray = Arrays.copyOf(oldArray, newCapacity);
    Arrays.fill(newArray, oldCapacity, newArray.length, UNSET);
    newArray[index] = value;
    indexedVariables = newArray;
}


public static void fill(Object[] a, int fromIndex, int toIndex, Object val) {
    rangeCheck(a.length, fromIndex, toIndex);
    for (int i = fromIndex; i < toIndex; i++)
        a[i] = val;
}

关于新数组长度的代码，还是看个例子来看得明白。

public class FastThreadLocalTest5 {

    public static void main(String[] args) {
        for(int i = 1;i <= 35 ;i ++){
            System.out.println("i = " + i  + ", newCapacity = " + (newCapacity(i)));
        }
    }
    
    public static int newCapacity(int newCapacity) {
        newCapacity |= newCapacity >>> 1;
        newCapacity |= newCapacity >>> 2;
        newCapacity |= newCapacity >>> 4;
        newCapacity |= newCapacity >>> 8;
        newCapacity |= newCapacity >>> 16;
        newCapacity++;
        return newCapacity;
    }
}

假如index值从1~35之间，那么新生成数组的容量如下。
在这里插入图片描述
看过HashMap源码的对上述扩容操作肯定不陌生，这么做的目的就是为了保证数组的长度一定是2的倍数。那expandIndexedVariableTableAndSet()接下来的步骤就简单多了，将旧数组复制到新数组，初始化新数组未填充的槽位为InternalThreadLocalMap.UNSET，再调用newArray[index] = value，将值保存到新数组中，接着indexedVariables 指向新数组。都很简单，这里就不深入了。当然值设置好后，调用addToVariablesToRemove()方法，将当前FastThreadLocal变量记录到 Set<FastThreadLocal<?>>中，看其代码实现。

private static void addToVariablesToRemove(InternalThreadLocalMap threadLocalMap, FastThreadLocal<?> variable) {
    Object v = threadLocalMap.indexedVariable(variablesToRemoveIndex);
    Set<FastThreadLocal<?>> variablesToRemove;
    if (v == InternalThreadLocalMap.UNSET || v == null) {
        variablesToRemove = Collections.newSetFromMap(new IdentityHashMap<FastThreadLocal<?>, Boolean>());
        threadLocalMap.setIndexedVariable(variablesToRemoveIndex, variablesToRemove);
    } else {
        variablesToRemove = (Set<FastThreadLocal<?>>) v;
    }

    variablesToRemove.add(variable);
}

当然啦，如果没有初始化Set<FastThreadLocal<?>> ，则会调用Collections.newSetFromMap(new IdentityHashMap<FastThreadLocal<?>, Boolean>());初始化variablesToRemove，并将初始化好的值设置到threadLocalMap的indexedVariables[variablesToRemoveIndex]位置，如果已经存储，则直接调用add()方法，将FastThreadLocal记录到variablesToRemove即可。为什么用IdentityHashMap，而不用HashMap，IdentityHashMap有哪些特性呢？

IdentityHashMap特性。

IdentityHashMap中的 key 允许重复
IdentityHashMap使用的是 == 比较 key 的值（比较内存地址），而 HashMap 使用的是 equals()（比较存储值）
IdentityHashMap使用的是 System.identityHashCode(object) 查找位置，HashMap 使用的是 hashCode() 查找位置
IdentityHashMap理论上来说速度要比 HashMap 快一点

我猜使用IdentityHashMap也是Netty追求性能的极致体验吧。

还有一个比较好奇的是newSetFromMap内部做了哪些事情呢？

public static <E> Set<E> newSetFromMap(Map<E, Boolean> map) {
    return new SetFromMap<>(map);
}

就创建了一个SetFromMap对象，什么都没有做，那SetFromMap的类结构是什么呢？

private static class SetFromMap<E> extends AbstractSet<E>
    implements Set<E>, Serializable
{
    private final Map<E, Boolean> m;  // The backing map
    private transient Set<E> s;       // Its keySet

    SetFromMap(Map<E, Boolean> map) {
        if (!map.isEmpty())
            throw new IllegalArgumentException("Map is non-empty");
        m = map;
        s = map.keySet();
    }

    public void clear()               {        m.clear(); }
    public int size()                 { return m.size(); }
    public boolean isEmpty()          { return m.isEmpty(); }
    public boolean contains(Object o) { return m.containsKey(o); }
    public boolean remove(Object o)   { return m.remove(o) != null; }
    public boolean add(E e) { return m.put(e, Boolean.TRUE) == null; }
    public Iterator<E> iterator()     { return s.iterator(); }
    public Object[] toArray()         { return s.toArray(); }
    public <T> T[] toArray(T[] a)     { return s.toArray(a); }
    public String toString()          { return s.toString(); }
    public int hashCode()             { return s.hashCode(); }
    public boolean equals(Object o)   { return o == this || s.equals(o); }
    public boolean containsAll(Collection<?> c) {return s.containsAll(c);}
    public boolean removeAll(Collection<?> c)   {return s.removeAll(c);}
    public boolean retainAll(Collection<?> c)   {return s.retainAll(c);}
    // addAll is the only inherited implementation

    // Override default methods in Collection
    @Override
    public void forEach(Consumer<? super E> action) {
        s.forEach(action);
    }
    @Override
    public boolean removeIf(Predicate<? super E> filter) {
        return s.removeIf(filter);
    }

    @Override
    public Spliterator<E> spliterator() {return s.spliterator();}
    @Override
    public Stream<E> stream()           {return s.stream();}
    @Override
    public Stream<E> parallelStream()   {return s.parallelStream();}

    private static final long serialVersionUID = 2454657854757543876L;

    private void readObject(java.io.ObjectInputStream stream)
        throws IOException, ClassNotFoundException
    {
        stream.defaultReadObject();
        s = m.keySet();
    }
}

构造SetFromMap对象时，m 为传入的new IdentityHashMap<FastThreadLocal<?>, Boolean>()，而s 则是m key 的集合，而记录FastThreadLocal就是将FastThreadLocal作为key 添加到m中，而值用Boolean类型，我猜是为了节省存储空间吧。先放到这里，以后用到时再来分析SetFromMap结构。当然啦，在set()方法中有另外一种情况，如果设置的值是InternalThreadLocalMap.UNSET，相当于调用remove()方法，接下来看remove()方法的实现。

public final void remove() {
    remove(InternalThreadLocalMap.getIfSet());
}

public final void remove(InternalThreadLocalMap threadLocalMap) {
    if (threadLocalMap == null) {
        return;
    }

    Object v = threadLocalMap.removeIndexedVariable(index);
    removeFromVariablesToRemove(threadLocalMap, this);

    if (v != InternalThreadLocalMap.UNSET) {
        try {
            onRemoval((V) v);
        } catch (Exception e) {
            PlatformDependent.throwException(e);
        }
    }
}

protected void onRemoval(@SuppressWarnings("UnusedParameters") V value) throws Exception { }

和set()方法原理一样，先将当前FastThreadLocal从threadLocalMap移除掉，再将当前FastThreadLocal从Set<FastThreadLocal<?>> 记录中移除掉。当然啦,onRemoval()方法提供给子类实现。先来看removeIndexedVariable()方法的实现。

public Object removeIndexedVariable(int index) {
    Object[] lookup = indexedVariables;
    if (index < lookup.length) {
        Object v = lookup[index];
        lookup[index] = UNSET;
        return v;
    } else {
        return UNSET;
    }
}

当然removeIndexedVariable()方法和setIndexedVariable()功能一样，直接设置indexedVariables[index]的值为UNSET即可。接下来看removeFromVariablesToRemove()方法。

private static void removeFromVariablesToRemove(
        InternalThreadLocalMap threadLocalMap, FastThreadLocal<?> variable) {

    Object v = threadLocalMap.indexedVariable(variablesToRemoveIndex);

    if (v == InternalThreadLocalMap.UNSET || v == null) {
        return;
    }

    @SuppressWarnings("unchecked")
    Set<FastThreadLocal<?>> variablesToRemove = (Set<FastThreadLocal<?>>) v;
    variablesToRemove.remove(variable);
}

当然，removeFromVariablesToRemove()方法的原理也很简单，从indexedVariables中取出索引位置为variablesToRemoveIndex的值，如果存在，则调用其remove()方法。当然，remove() 方法和add()方法相对应，直接将 FastThreadLocal 从IdentityHashMap移除即可，是不是很简单，理论上比ThreadLocal的源码简单多了。

接下来看FastThreadLocal的get()方法。

public final V get(InternalThreadLocalMap threadLocalMap) {
    Object v = threadLocalMap.indexedVariable(index);
    if (v != InternalThreadLocalMap.UNSET) {
        return (V) v;
    }
    return initialize(threadLocalMap);
}

public Object indexedVariable(int index) {
    Object[] lookup = indexedVariables;
    return index < lookup.length? lookup[index] : UNSET;
}

private V initialize(InternalThreadLocalMap threadLocalMap) {
    V v = null;
    try {
        v = initialValue();
    } catch (Exception e) {
        PlatformDependent.throwException(e);
    }
    threadLocalMap.setIndexedVariable(index, v);
    addToVariablesToRemove(threadLocalMap, this);
    return v;
}

protected V initialValue() throws Exception {
    return null;
}

其实上面代码看是去一大堆，实现原理还是很简单的，在整个Java程序运行过程中每一个FastThreadLocal对应一个index，因此只需要根据当前index到indexedVariables数组中查找值即可，但有一点需要注意，如果FastThreadLocal之前没有set()保存过值，此时调用get()方法，会触发initialize(threadLocalMap)方法的调用，这做做的用意是什么呢？再来看一个例子。
在这里插入图片描述

当调用get()方法时，如果此时FastThreadLocal并没有调用set()方法设置值，此时会触发initialValue()方法调用，默认的initialValue()方法返回null，如果FastThreadLocal重写了initialValue()方法，则返回重写initialValue()之后的方法返回值，并且将该值保存到indexedVariables[index]中，同时将当前FastThreadLocal记录到线程的Set<FastThreadLocal<?>> variablesToRemove 属性中。 remove()方法之前分析过了，现在只需要看removeAll()方法的实现。

public static void removeAll() {
    InternalThreadLocalMap threadLocalMap = InternalThreadLocalMap.getIfSet();
    if (threadLocalMap == null) {
        return;
    }
    try {
        Object v = threadLocalMap.indexedVariable(variablesToRemoveIndex);
        if (v != null && v != InternalThreadLocalMap.UNSET) {
            @SuppressWarnings("unchecked")
            Set<FastThreadLocal<?>> variablesToRemove = (Set<FastThreadLocal<?>>) v;
            // 将set 集合转化为数组，可能是提升性能的体现吧
            FastThreadLocal<?>[] variablesToRemoveArray =
                    variablesToRemove.toArray(new FastThreadLocal[0]);
            for (FastThreadLocal<?> tlv: variablesToRemoveArray) {
            	// 调用FastThreadLocal的remove方法
                tlv.remove(threadLocalMap);
            }
        }
    } finally {
        InternalThreadLocalMap.remove();
    }
}

大家需要注意，removeAll()方法是一个静态方法，因此调用时，直接用FastThreadLocal.removeAll()调用即可。当然之前也简单的分析了一下removeAll()方法，这里继续来分析。第一步，通过variablesToRemoveIndex找到记录当前线程所有FastThreadLocal的Set集合。如果不为空且不为InternalThreadLocalMap.UNSET，则证明 Set<FastThreadLocal<?>> variablesToRemove之前设置过值，很大可能有FastThreadLocal需要被清理。接下来看InternalThreadLocalMap的remove()方法。

public static void remove() {
    Thread thread = Thread.currentThread();
    if (thread instanceof FastThreadLocalThread) {
        ((FastThreadLocalThread) thread).setThreadLocalMap(null);
    } else {
        slowThreadLocalMap.remove();
    }
}

直接将线程的threadLocalMap设置为空即可，当然还有一种情况就是当前线程不是FastThreadLocalThread时，那所有的操作都是ThreadLocal的操作，之前分析过ThreadLocal源码这里就不深入分析了，关于FastThreadLocal的源码就分析到这里了。

总结

关于ThreadLocal ，FastThreadLocal和的源码就分析到这里了，他们谁更好呢？

从源码的角度上来看，你会发现ThreadLocal的源码要难得多，各种情况都考虑得比较全面，FastThreadLocal相对而言更加简单。
从性能上来看，FastThreadLocal的性能绝对的快，只需要从数组直接取出当前FastThreadLocal 对应的值即可，在使用static 情况下ThreadLocal的性能和FastThreadLocal一样，但如果在方法中大量使用本地ThreadLocal ，可能在插入和查找过程中，需要从索引处不断的向后查找，最坏情况可能需要查找(table.length * 2 / 3 )次，为什么是这个值呢？因为当table数组的元素个数大于等于这个值时，就可能触发扩容，对于 get()方法而言，在查找过程中，只需要查找到table[i] 为空时，如果还没有查找到ThreadLocal对应的Entry，就不再进行查找，对于set()方法而方，如果查找到table[i]为空时，就可以将当前ThreadLocal 设置到table[i]中，当然在插入，移除，和查找过程中，会触发table重置ThreadLocal的位置，也会带来性能损失，但空间利用率上，ThreadLocal显然比FastThreadLocal高得多，ThreadLocal在插入，移除，和查找过程中都会去移除被JVM回收的ThreadLocal及其值，table数组不会存在太多的内存浪费，但FastThreadLocal中完全是以空间换时间的方式，如果0~10000的index被其他FastThreadLocal用过，此时新使用的FastThreadLocal的数组长度就需要大于10000的长度，而之前所被其他FastThreadLocal使用过的槽位都只能指向一个InternalThreadLocalMap.UNSET ,一个空对象的引用，即使一个引用占4b ,那么 10000 * 4b = 40kb 的内存空间，当然啦，实际情况并不仅仅浪费那么多。如果前面10000个index都被其他FastThreadLocal，当前线程需要创建一个16384长度的数组来存储FastThreadLocal的value值，但实际情况真创建那么多吗？也不好说，因此FastThreadLocal相对于ThreadLocal是比较浪费空间的。
在使用上ThreadLocal肯定比FastThreadLocal使用简单，因为ThreadLocal即使没有手动remove()，系统也会帮你回收内存空间，但FastThreadLocal如果没有手动remove()，就可能出现内存泄漏了。

因此综合上述，对于自己开发的框架，并且对内存占用不是很严苛场景，使用FastThreadLocal当然是好的，这样能极大的提升性能，将ThreadLocal可能导致的性能问题完全屏蔽掉，对于一个高并发程序来说是值得的，只要自己代码写得没有bug即可。但对于开源让大家都来使用代码，还是建议使用ThreadLocal，因为ThreadLocal底层帮我们默默的做了很多优化的地方，同时使用起来也更加简单，很多程序员忘记调用ThreadLocal的remove()方法，也不会带来什么问题，如果使用FastThreadLocal来供所有开发人员使用的话，肯定会带来很多不必要的麻烦，因此ThreadLocal 更像放之四海而皆准的东西，而FastThreadLocal更像vip ，需要有一定素养，对FastThreadLocal底层比较了解的程序员才能使用。因此说谁好，谁不好，还是看具体的应用场景吧。

关于FastThreadLocal的使用，在后面具体的Netty 源码再来分析