Netty源码学习（七）FastThreadLocal
0. FastThreadLocal简介
如同注释中所说：A special variant of ThreadLocal that yields higher access performance when accessed from a FastThreadLocalThread.
这是ThreadLocal的变种，但是有更高的性能
ps.本文涉及的源码版本如下：
JDK : java-1.8.0-openjdk-1.8.0.141-1.b16.ojdkbuild.windows.x86_64
Netty : 4.1.15.Final
1. JDK自带的ThreadLocal的工作原理，以及存在的问题
原理简介：
a. 每个线程内部维护了一个ThreadLocal.ThreadLocalMap类型的变量threadLocals
b. ThreadLocalMap是由数组实现的Map，key为ThreadLocal，value为对应的变量
c. 对ThreadLocal进行get/set操作时，会先获取当前Thread内部的ThreadLocal.ThreadLocalMap，然后以ThreadLocal为key，从这个Map中获取对应的value就是结果
设计理念：
a. ThreadLocal中的数据实际存放于Thread中，线程死亡时，这些数据会被自动释放，减小了开销
b. 一般来说，一个ThreadLocal对应的Thread数量远多于一个Thread所对应的ThreadLocal数量，因此Thead内部维护的ThreadLocal.ThreadLocalMap的长度一般来说是较短的，寻址快速
存在的问题：
直接跟踪ThreadLocal.get()方法的调用链：
ThreadLocalMap.get() public T get() { Thread t = Thread.currentThread(); ThreadLocalMap map = getMap(t);//获取当前线程内部维护的ThreadLocalMap对象 if (map != null) { ThreadLocalMap.Entry e = map.getEntry(this);//以当前TheadLocal为key，在ThreadLocalMap中查询数据 if (e != null) { @SuppressWarnings("unchecked") T result = (T)e.value; return result; } } return setInitialValue(); } ThreadLocal.ThreadLocalMap.getEntry() /** * Get the entry associated with key. This method * itself handles only the fast path: a direct hit of existing * key. It otherwise relays to getEntryAfterMiss. This is * designed to maximize performance for direct hits, in part * by making this method readily inlinable. * * @param key the thread local object * @return the entry associated with key, or null if no such */ private Entry getEntry(ThreadLocal<?> key) { int i = key.threadLocalHashCode & (table.length - 1);//ThreadLocal的threadLocalHashCode是在定义ThreadLocal时产生的一个伪随机数，可以理解为ThreadLocal的hashCode，此处用其计算ThreadLocal在ThreadLocalMap中的下标 Entry e = table[i];//寻址 if (e != null && e.get() == key)//命中 return e; else return getEntryAfterMiss(key, i, e);//未命中，目标地址上存储了另外一个ThreadLocal及其对应的value(hash碰撞) } ThreadLocal.ThreadLocalMap.getEntryAfterMiss() 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);//如果key为null，则删除对应的value（由于ThreadLocalMap中的Entry扩展于WeakReference，因此如果ThreadLocal没有强引用的情况下，ThreadLocal会被gc回收掉，此时key为空。为了便于gc，需要同时删除对value的引用） else i = nextIndex(i, len);//查找ThreadLocalMap中的下一个元素，直到命中为止（很明确的线性探测法） e = tab[i]; } return null; }
代码逻辑不算复杂，其问题在于在ThreadLocal.ThreadLocalMap中查找时，采用的是线性探测法，一般情况下时间复杂度是O(1)，但是在发生哈希冲突时，可能会退化到O(n)的时间复杂度。
Netty中针对此处做出了下面的优化
2. Netty中的FastThreadLocal原理
原理简介：
a. FastThreadLocal的构造方法中，会为当前FastThreadLocal分配一个index，这个index是由一个全局唯一的static类型的AtomInteger产生的，可以保证每个FastThreadLocal的index都不同
b. FastThreadLocal需要与FastThreadLocalThread配套使用（FastThreadLocalThread内部维护了一个InternalThreadLocalMap类型的threadLocalMap属性，在调用FastThreadLocal的get方法时会去这个InternalThreadLocalMap中查询）
c. InternalThreadLocalMap内部也是使用数组作为底层存储，key为FastThreadLocal，寻址方式是直接使用FastThreadLocal内部维护的index，由于每个FastThreadLocal的index都不同，因此不会发生hash冲突，直接取数据即可，效率极高
d. 代价是有多少个FastThreadLocal对象， InternalThreadLocalMap内部就得开多大的底层数组（为了防止频繁扩容，实际上还要略大一点），也就是空间换时间了
源码分析：
//FastThreadLocal的构造方法中创建全局唯一的index的过程 public FastThreadLocal() { index = InternalThreadLocalMap.nextVariableIndex(); } static final AtomicInteger nextIndex = new AtomicInteger(); public static int nextVariableIndex() { int index = nextIndex.getAndIncrement(); if (index < 0) { nextIndex.decrementAndGet(); throw new IllegalStateException("too many thread-local indexed variables"); } return index; } FastThreadLocal.get() public final V get() { return get(InternalThreadLocalMap.get()); } InternalThreadLocalMap.get()//先从当前线程中获取维护的InternalThreadLocalMap属性 public static InternalThreadLocalMap get() { Thread thread = Thread.currentThread(); if (thread instanceof FastThreadLocalThread) { return fastGet((FastThreadLocalThread) thread); } else { return slowGet(); } } InternalThreadLocalMap.fastGet() private static InternalThreadLocalMap fastGet(FastThreadLocalThread thread) { InternalThreadLocalMap threadLocalMap = thread.threadLocalMap(); if (threadLocalMap == null) { thread.setThreadLocalMap(threadLocalMap = new InternalThreadLocalMap()); } return threadLocalMap; } 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;//indexedVariables就是InternalThreadLocalMap的底层数组了 return index < lookup.length? lookup[index] : UNSET; }
逻辑还是比较清晰的，我就不再做解释了
3. 总结
Netty的FastThreadLocal与JDK自带的ThreadLocal的设计理念实际上还是相通的，都是在Thread的内部维护了一个Map，然后把数据记录在其中，只是Netty摒弃了JDK中采用的线性探测法，而是为每个FastThreadLocal对象生成一个全局唯一的index，并以此在Map中寻址，这样就直接解决了哈希冲突的问题。至于高性能与空间浪费的取舍，就见仁见智了。
