FastThreadLocal源码分析

概述

Netty源码分析时经常看到 FastThreadLocal 的身影，Netty 作为高性能的网络通信框架，FastThreadLocal 是比 JDK 自身的 ThreadLocal 性能更高的通信框架。FastThreadLocal 到底比 ThreadLocal 快在哪里呢？

一、JDK ThreadLocal

image

源码分析参考上一节，这里只做几点总结：

• 每个Thread有一个ThreadLocalMap
• ThreadLocal只是一个媒介，连接Thread与ThreadLocalMap
• ThreadLocalMap数组中每个节点是一个Entry(ThreadLocal -> value)
• 一个Thread可以有多个ThreadLocal但是只有一个ThreadLocalMap
• threadLocal.set时是把当前Thread的当前threadLocal作为key构造Entry放到ThreadLocalMap
• 当一个Thread有多个ThreadLocal时ThreadLocalMap数组中就有可能会出现冲突
• threadLocal.get时是从当前Thread的ThreadLocalMap中获取

内存泄漏
Entry 的 key 设计成了弱引用，但是当 ThreadLocal 不再使用被 GC 回收后，ThreadLocalMap 中可能出现 Entry 的 key 为 NULL，那么 Entry 的 value 一直会强引用数据而得不到释放，只能等待线程销毁。那么应该如何避免 ThreadLocalMap 内存泄漏呢？ThreadLocal 已经帮助我们做了一定的保护措施，在执行 ThreadLocal.set()/get() 方法时，ThreadLocal 会清除 ThreadLocalMap 中 key 为 NULL 的 Entry 对象，让它还能够被 GC 回收。除此之外，当线程中某个 ThreadLocal 对象不再使用时，立即调用 remove() 方法删除 Entry 对象。如果是在异常的场景中，记得在 finally 代码块中进行清理，保持良好的编码意识。

二、Netty FastThreadLocal

image

对比ThreadLocal结构图可以看出几点不同：1.InternalThreadLocalMap中并不是Entry的key-value结构，直接就是一个Object数组；其中索引0位置存放FastThreadLocal的Set集合，其他索引位置初始化为UNSET，有数据存入时更新为具体的Object；2.FastThreadLocal中包含一个自增的index表示在InternalThreadLocalMap的数组中的索引位置；这样就不用像JDK ThreadLocal一样通过拉链法解决冲突；3.Set<FastThreadLocal<?>>结构中存放FastThreadLocal的引用，就不用像JDK ThreadLocal中通过Entry key的虚引用指向堆种FastThreadLocal对象，更容易解决内存泄漏的问题；

三、FastThreadLocal源码分析

首先看下 FastThreadLocal.set() 的源码：

public final void set(V value) {
    if (value != InternalThreadLocalMap.UNSET) { // 1\. value 是否为缺省值
        InternalThreadLocalM