这玩意比ThreadLocal叼多了，吓得why哥赶忙分享出来。

这是why哥的第 70 篇原创文章

从Dubbo的一次提交开始

故事得从前段时间翻阅 Dubbo 源码时，看到的一段代码讲起。

这段代码就是这个：

org.apache.dubbo.rpc.RpcContext

使用 InternalThreadLocal 提高性能。

相信做为一个程序猿，都会被 improve performance（提高性能）这样的字眼抓住眼球。

内心开始痒痒的，必需要一探究竟。

刚看到这段代码的时候，我就想：既然他是要提高性能，那说明以前的东西表现的不太好。

那以前的东西是什么？

通过长时间的推理、缜密的分析，我大胆的猜想到以前的东西就是：ThreadLocal。

来，带你们看一下:

果不其然，我真是太厉害了。

2018 年 5 月 15 日的提交：New threadLocal provides more performance. (#1745)

能够看到此次提交的后面跟了一个数字：1745。它对应一个 pr，连接以下：

https://github.com/apache/dubbo/pull/1745

在这个 pr 里面仍是有不少有趣的东西的，出场人物一个比一个骚，文章的最后带你们看看。

能干啥用？

在说 ThreadLocal 和 InternalThreadLocal 以前，仍是先讲讲它们是干啥用的吧。

InternalThreadLocal 是 ThreadLocal 的加强版，因此他们的用途都是同样的，一言蔽之就是：传递信息。

你想象你有一个场景，调用链路很是的长。当你在其中某个环节中查询到了一个数据后，最后的一个节点须要使用一下。

这个时候你怎么办？你是在每一个接口的入参中都加上这个参数，传递进去，而后只有最后一个节点用吗？

能够实现，可是不太优雅。

你再想一想一个场景，你有一个和业务没有一毛钱关系的参数，好比 traceId ，纯粹是为了作日志追踪用。

你加一个和业务无关的参数一路透传干啥玩意？

一般咱们的作法是放在 ThreadLocal 里面，做为一个全局参数，在当前线程中的任何一个地方均可以直接读取。固然，若是你有修改需求也是能够的，视需求而定。

绝大部分的状况下，ThreadLocal 是适用于读多写少的场景中。

举三个框架源码中的例子，你们品一品。

第一个例子：Spring 的事务。

在个人早期做品《事务没回滚？来，咱们从现象到原理一块儿分析一波》里面，我曾经写过：

Spring 的事务是基于 AOP 实现的，AOP 是基于动态代理实现的。因此 @Transactional 注解若是想要生效，那么其调用方，须要是被 Spring 动态代理后的类。

所以若是在同一个类里面，使用 this 调用被 @Transactional 注解修饰的方法时，是不会生效的。

为何？

由于 this 对象是未经动态代理后的对象。

那么咱们怎么获取动态代理后的对象呢？

其中的一个方法就是经过 AopContext 来获取。

其中第三步是这样获取的：AopContext.currentProxy();

而后我还很是高冷的（咦，想一想就以为羞耻）说了句：对于 AopContext 我多说几句。

看一下 AopContext 里面的 ThreadLocal：

调用 currentProxy 方法时，就是从 ThreadLocal 里面获取当前类的代理类。

那他是怎么放进去的呢？

我高冷的第二句是这样说的：

对应的代码位置以下：

能够看到，通过一个 if 判断，若是为 true ，则调用 AopContext.setCurrentProxy 方法，把代理对象放到 AopContext 里面去。

而这个 if 判断的配置默认是 false，因此须要经过刚刚说的配置修改成 true，这样 AopContext 才会生效。

附送一个知识点给你，不客气。

第二个例子：mybatis 的分页插件，PageHelper。

使用方法很是简单，从官网上截个图：

这里它为何说：紧跟着的第一个 select 方法会被分页。

或者说：什么状况下会致使不安全的分页？

来，就当是一个面试题，而且我给你提示了：从 ThreadLocal 的角度去回答。

其实就是由于 PageHelper 方法使用了静态的 ThreadLocal 参数，分页参数和线程是绑定的：

若是咱们写出下面这样的代码，就是不安全的用法：

这种状况下因为 param1 存在 null 的状况，就会致使 PageHelper 生产了一个分页参数，可是没有被消费，这个参数就会一直保留在这个线程上，也就是放在线程的 ThreadLocal 里面。

当这个线程再次被使用时，就可能致使不应分页的方法去消费这个分页参数，这就产生了莫名其妙的分页。

上面这个代码，应该写成下面这个样子：

这种写法，就能保证安全。

核心思想就一句话：只要你能够保证在 PageHelper 方法调用后紧跟 MyBatis 查询方法，这就是安全的。

由于 PageHelper 在 finally 代码段中自动清除了 ThreadLocal 存储的对象。

就算代码在进入 Executor 前发生异常，致使线程不可用的状况，好比常见的接口方法名称和 XML 中的不匹配，致使找不到 MappedStatement ，因为自动清除，也不会致使 ThreadLocal 参数被错误的使用。

因此，我看有的人为了保险起见这样去写：

怎么说呢，这个代码....

第三个例子：Dubbo 的 RpcContext。

RpcContext 这个对象里面维护了两个 InternalThreadLocal，分别是存放 local 和 server 的上下文。

也就是咱们说的加强版的 ThreadLocal：

做为一个 Dubbo 应用，它既多是发起请求的消费者，也多是接收请求的提供者。

每一次发起或者收到 RPC 调用的时候，上下文信息都会发生变化。

好比说：A 调用 B，B 调用 C。这个时候 B 既是消费者也是提供者。

那么当 A 调用 B，B 仍是没调用 C 以前，RpcContext 里面保存的是 A 调用 B 的上下文信息。

当 B 开始调用 C 了，说明 A 到 B 以前的调用已经完成了，那么以前的上下文信息就应该清除掉。

这时 RpcContext 里面保存的应该是 B 调用 C 的上下文信息。不然会出现上下文污染的状况。

而这个上下文信息里面的一部分就是经过InternalThreadLocal存放和传递的，是 ContextFilter 这个拦截器维护的。

ThreadLocal 在 Dubbo 里面的一个应用就是这样。

固然，还有不少不少其余的开源框架都使用了 ThreadLocal 。

能够说使用频率很是的高。

什么？你说你用的少？

那可不咋的，人家都给你封装好了，你当个黑盒，开箱即用。

其实你用了，只是你不知道而已。

强在哪里？

前面说了 ThreadLocal的几个应用场景，那么这个 InternalThreadLocal 到底比 ThreadLocal 强在什么地方呢？

先说结论。

答案其实就写在类的 javadoc 上：

InternalThreadLocal 是 ThreadLocal 的一个变种，当配合 InternalThread 使用时，具备比普通 Thread 更高的访问性能。

InternalThread 的内部使用的是数组，经过下标定位，很是的快。若是遇得扩容，直接数组扩大一倍，完事。

而 ThreadLocal 的内部使用的是 hashCode 去获取值，多了一步计算的过程，并且用 hashCode 必然会遇到 hash 冲突的场景，ThreadLocal 还得去解决 hash 冲突，若是遇到扩容，扩容以后还得 rehash ,这可不得慢吗？

数据结构都不同了，这其实就是这两个类的本质区别，也是 InternalThread 的性能在 Dubbo 的这个场景中比 ThreadLocal 好的根本缘由。

而 InternalThread 这个设计思想是从 Netty 的 FastThreadLocal 中学来的。

本文主要聊聊 InternalThread ，可是我但愿的是你们能学到这个类的思想，而不是用法。

首先，咱们先搞个测试类：

public class InternalThreadLocalTest {

    private static InternalThreadLocal<Integer> internalThreadLocal_0 = new InternalThreadLocal<>();

    public static void main(String[] args) {
        new InternalThread(() -> {
            for (int i = 0; i < 5; i++) {
                internalThreadLocal_0.set(i);
                Integer value = internalThreadLocal_0.get();
                System.out.println(Thread.currentThread().getName()+":"+value);
            }
        }, "internalThread_have_set").start();

        new InternalThread(() -> {
            for (int i = 0; i < 5; i++) {
                Integer value = internalThreadLocal_0.get();
                System.out.println(Thread.currentThread().getName()+":"+value);
            }
        }, "internalThread_no_set").start();
    }
}

上面代码的运行结果是这样的：

因为 internalThread_no_set 这个线程没有调用 InternalThreadLocal 类的 set 方法，因此调用 get 方法输出为 null。

里面主要用到了 set、get 这一对方法。

下面借助 set 方法，带你们看看内部原理（先说一下，为了方便截图，我有可能会调整一下源码顺序）：

首先是判断了传进来的 value 是不是 null 或者是 UNSET，若是是则调用 remove 方法。

null 是好理解的。这个 UNSET 是个什么鬼？

根据 UNSET 能很容易的找到这个地方：

原来是 InternalThreadLocalMap 初始化的时候会填充 UNSET 对象。

因此，若是 set 的对象是 UNSET，咱们能够认为是须要把当前位置上的值替换为 UNSET，也就是 remove 掉。

并且，咱们还看到了两个关键的信息：

1.InternalThreadLocalMap 虽然名字叫作 Map ，可是它挂羊头卖狗肉，其实里面维护的是一个数组。

2.数组初始化大小是 32。

接着咱们回去看 else 分支的逻辑：

调用的是 InternalThreadLocalMap 对象的 get 方法。

而这个方法里面的两个 get 就有趣了。

能走到 fastGet 方法的，说明当前线程是 InternalThread 类，直接能够获取到类里面的 InternalThreadLocalMap。

若是走到 slowGet 了，则回退到原生的 ThreadLocal ，只是在原生的里面，我仍是放的 InternalThreadLocalMap：

因此，其实线程上绑定的数据都是放到 InternalThreadLocalMap 里面的，无论你操做什么 ThreadLocal，实际上都是操做的 InternalThreadLocalMap。

那问题来了，你以为一个叫作 fastGet ，一个叫作 slowGet。这个快慢，指的是 get 什么东西的快慢？

对咯，就是获取 InternalThreadLocalMap。

InternalThreadLocalMap 在 InternalThread 里面是一个变量维护的，能够直接经过 InternalThread.threadLocalMap() 得到：

标号为 ① 的地方是获取，标号为 ② 的地方是设置。

都是一步到位，操做起来很是的方便。

这是 fastGet。

而 slowGet 是从 ThreadLocal 中获取：

这里的 get ，就是原生 ThreadLocal 的 get 方法，一眼望去，就复杂多了：

标号为 ① 的地方，首先计算 hash 值，而后拿着 hash 值去数组里面取数据。若是取出来的数据不是咱们想要的数据，则到标号为 ② 的逻辑里面去。

那么我问你，除了这个位置上的值真的为 null 外，还有什么缘由会致使我拿着计算出来的 hash 值去数组里面取数据取不到？

就是看你熟不熟悉 ThreadLocal 对 hash 冲突的处理方式了。

那么这个问题稍微的升级一下就是：你知道哪些 hash 冲突的解决方案呢？

1.开放定址法。

2.链式地址法。

3.再哈希法。

4.创建公共溢出区。

咱们很是熟悉的 HashMap 就是采用的链式地址法解决 hash 冲突。

而 ThreadLocal 用的就是开放定址法中的线性探测。

所谓线性探测就是，若是某个位置的值已经存在了，那么就在原来的值上日后加一个单位，直至不发生哈希冲突，就像这样的：

上面的动图就是须要在一个长度为 7 的数组里面，再放一个进过 hash 计算后为下标为 2 的数据，可是该位置上有值，也就是发生了 hash 冲突。

因而解决 hash 冲突的方法就是一次次的日后移，直到找到没有冲突的位置。

因此，当咱们取值的时候若是发生了 hash 冲突也须要日后查询，这就是上面标号为 ③ 的 while 循环代码的其中一个目的。

固然还有其余目的，就隐藏在 440 行的 expungeStaleEntry 方法里面。不是本文重点，就很少说了。

可是若是你不知道这个方法，你必定要去查阅一下相关的资料，有可能会在必定程度上改变你印象中的：用 ThreadLocal 会致使内存泄漏的风险。

至少，你能够知道 JDK 为了不内存泄漏的问题，是作了本身的最大努力的。

好了，不扯远了，说回来。

从上面咱们知道了，从 ThreadLocal 中获取 InternalThreadLocalMap 会经历以下步骤：

1.计算 hash 值。

2.判断经过 hash 值是否能直接获取到目标对象。

3.若是没有获取到目标对象则日后遍历，直至获取成功或者循环结束。

比从 InternalThread 里面获取 InternalThreadLocalMap 复杂多了。

如今你知道了 fastGet/slowGet 这个两个方法中的快慢，指的是从两个不一样的 ThreadLocal 中获取 InternalThreadLocalMap 的操做的快慢。而快慢的根本缘由是数据结构的差别。

好，如今咱们获取到 InternalThreadLocalMap 了，接着看 set 方法：

标号为 ① 的地方就是往 InternalThreadLocalMap 这个数组中存放咱们传进来的 value。

存的时候分为两种状况。

标号为 ② 的地方是数组容量还够，能放进去，那么能够直接设置。

标号为 ③ 的地方是数组容量不够用，须要扩容了。

这里抛出两个问题：

扩容是怎么扩的？

数组下标是怎么来的？

先看问题一，怎么扩容的？

看源码：

怎么样，看到的第一眼你想到了什么？

大声的说出来，是否是想到了 HashMap 里面的一段源码？

和 HashMap 里面的位运算殊途同归。

在 InternalThreadLocalMap 中扩容就是变成原来大小的 2 倍。从 32 到 64，从 64 到 128 这样。

扩容完成以后把原数组里面的值拷贝到新的数组里面去。

而后剩下的部分用 UNSET 填充。最后把咱们传进来的 value 放到指定位置上。

再看看问题二，数组下标怎么来的？也就是这个 index：

从上往下看，能够看到最后，这个 index 本质上是一个 AtomicInteger 。

主要看一下标号为 ① 的地方。

index 每次都是加一，对应的是 InternalThreadLocalMap 里的数组下标。

第一眼看到的时候，里面的 if 判断 index<0 我是能够理解的，防止溢出嘛。

可是下面在抛出异常以前，还调用了 decrementAndGet 方法，又把值减回去了。

你说这是为何？

开始我没想明白。可是有天晚上睡觉以前，电光火石一瞬间我想明白了。

若是不把值减回去，加一的代码还在不断的被调用，那么这个 index 理论上讲是有可能又被加到正数的，这一点你能明白吧？

为何我说理论上呢？

int 的取值范围是 [-2147483648 到 2147483647]。

若是 int 从 0 增长，一直溢出到 -2147483648，再从 -2147483648 加到 0，中间有 4294967295 个数字。

一个数字对应数组的一个下标，就算里面放的是一个字节的 boolean 型，那么大概也就是 4T 的内存吧。

因此，我以为这是理论上的。

到这一步，咱们已经完成了从 Thread 里面取出 InternalThreadLocalMap ，而且往里面放数据的操做。

最后，InternalThreadLocal 的 set 方法只剩下最后一行代码，咱们还没说：

就是 setIndexedVariable 方法返回 true 后，会执行 addToVariablesToRemove 方法。

这个方法其实就是在数组的第一个位置维护当前线程里面的全部的 InternalThreadLocalMap 。

这里的关键点其实就是这个变量：

static final，能保证 VARIABLE_TO_REMOVE_INDEX 恒等于 0，也就是数组的第一个位置。

用示例程序，给你们演示一下，它第一个位置放的东西：

在第 21 行打上断点，而后看一下执行完 addToVariablesToRemove 方法后，InternalThreadLocalMap 数组的状况：

诚不欺你，第 0 个位置上放的是全部的 InternalThreadLocal 的集合。

因此，咱们看一下它的 size 方法，就能明白这里为何要减一了：

那么在第一个位置维护线程里面全部的 InternalThreadLocal 集合的用处是什么？

看看它的 removeAll 方法：

直接从数组中取出第 0 个位置的数据，而后循环干掉它就行。

set 方法就分析到这里啦，算是保姆级的一行行手把手教学了吧。

借助这个方法，也带你们看了内部结构。

点到为止。get 方法很简单的，你们记得本身去看一下哦。

咱们再看一下此次 pr 提交的东西：

咱们看看这四个线程池有什么变化：

就是换了工厂类。

换工厂类的目的是什么呢？

newThread 的时候，new 的是 InternalThread 线程。

好一个偷天换日。

前面咱们说了，要用改造版的 ThreadLocal ，必需要配合 InternalThread 线程使用，不然就会退化为原生的 ThreadLocal 。

其实， Dubbo 此次提交，改造的东西并很少。关键的、核心的代码都是从 Netty 那边 copy 过来的。

我这就是一个引子，你们能够再去看看 Netty 的 FastThreadLocal 类。

关于此次 pr 提交

接下来又是 get 奇怪知识点的时刻了。

前面说了，这个 pr 里面出场人物一个比一个“骚”，这一节我带你们看一下，是怎么个“骚”法。

https://github.com/apache/dubbo/pull/1745·

首先是 pr 的提交者，carryxyh 同窗的代码在 2018 年 5 月 15 日的时候被 merge 了：

正常来讲，carryxyh 同窗对于开源社区的一次贡献就算是完美结束了，简历上又能够浓墨重彩的写上一小笔。

可是 15 天以后发生的事情，多是他作梦也想不到的。

那一天，一个叫作 normanmaurer 的哥们在这个 pr 下面说了一句话：

先无论他说的啥。

你知道他是谁吗？他在我以前的文章中其实也出现过的。

他就是 Netty 的爸爸。

他是这样说的：

他的意思就是说：

哥们，你这个东西我怎么以为是从 Netty 那边弄过来的呢？本着开源的精神，你直接弄过来是没有问题的，可是你至少得按照规矩办事吧？得遵循 AL2 协议来。并且我甚至看到你在你的 pr 里面提到了 Netty 。

至于这个 AL2 究竟是什么，我是没有看明白的。

可是不重要，我就把它理解为一个给开源社区贡献代码时须要遵照的一个协议吧。

carryxyh 同窗看到 Netty 的爸爸找他了，很快就回复了两条消息：

carryxyh同窗说道：

老哥，我在 javadoc 里面提到了，个人灵感来源就是 Netty 的 FastThreadLocal 类。我写这个的目的就是告诉全部看到这个类的朋友，这里的大部分代码来自 Netty。

那我除了在 javadoc 里面写上来源是 Netty 外，还须要作什么吗？还有你说的 AL2 是什么东西，你能不能告诉我？

我必定会尽快修复的。

这么一来一回，我大概明白这两我的在说什么了。

Netty 的爸爸说你用了个人代码，这彻底没有问题，可是你得遵循一个协议哦。

carryxyh 同窗说，我已经在 javadoc 里说了我这部分代码就是来自 Netty 的，我真不知道还该作什么，请你告诉我。

Netty 的爸爸回复了一个连接：

他说：你就看着这个连接，按照它整就行。

他发的这个连接我看了，怎么说呢，很是的哇塞，纯英文，内容很是的多。先不关注是啥吧，反正 carryxyh 同窗确定会认真阅读的。

在 carryxyh 同窗没有回复以前，一个叫作 justinmclean 的哥们出来对 Netty 的爸爸说话了：

他说：实际上，ALv2 许可证已经不适用了，有新的政策出来了，以新的通知和许可证文件为准。

这个哥们既然这样轻描淡写的说有新政策了。我潜意识就以为他不是一个通常人，因而我查了一下：

主席、30年+、PMC、导师......

还愣着干吗，开始端茶吧。

大佬都出来了，接下来的对话大概也就是围绕着怎么才是一次符合开源标准的提交。

主席说，到底需不须要声明版权，得看代码的改造点多很少。

Netty 的爸爸说：据我所知，除了包名和类名不同外，其余的基本没有变化。

最终 carryxyh 同窗说把 Netty 的 FastThreadLocal 的文件头弄过来，是否是就完事了，

主席说：没毛病，我就是这样想的。

因此，咱们如今在 Dubbo 的 InternalThreadLocal 文件的最开始，还能够看到这样的 Netty 的说明：

这个东西，就是这样来的，不是随便写的，是有讲究。

好了，这应该是我全部文章中出现过的第 9 个用不上的傻吊知识点了吧。送给你，没必要客气。

好了，此次的文章就到这里啦。