这玩意比ThreadLocal叼多了,吓得我赶紧分享出来。
共 3871字,需浏览 8分钟
·
2020-12-13 21:30
点击上方 好好学java ,选择 星标 公众号
重磅资讯、干货,第一时间送达
重磅资讯、干货,第一时间送达
今日推荐:硬刚一周,3W字总结,一年的经验告诉你如何准备校招!
个人原创100W+访问量博客:点击前往,查看更多
个人原创100W+访问量博客:点击前往,查看更多
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 ,由于 finally 的自动清除,也不会导致 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 的内部使用的是数组,通过下标定位,非常的快。如果遇得扩容,直接搞一个扩大一倍的数组,然后copy 原数组,多余位置用指定对象填充,完事。
而 ThreadLocal 的内部使用的是 hashCode 去获取值,多了一步计算的过程,而且用 hashCode 必然会遇到 hash 冲突的场景,ThreadLocal 还得去解决 hash 冲突,如果遇到扩容,扩容之后还得 rehash ,这可不得慢吗?
数据结构都不一样了,这其实就是这两个类的本质区别,也是 InternalThread 的性能在 Dubbo 的这个场景中比 ThreadLocal 好的根本原因。
而 InternalThread 这个设计思想是从 Netty 的 FastThreadLocal 中学来的。
本文主要聊聊 InternalThread ,但是我希望的是大家能学到这个类的思想,而不是用法。
首先,我们先搞个测试类:
public class InternalThreadLocalTest {
private static InternalThreadLocal 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 的说明:
这个东西,就是这样来的,不是随便写的,是有讲究。
推荐文章
原创电子书
历时整整一年总结的 Java 面试 + Java 后端技术学习指南,这是本人这几年及校招的总结,各种高频面试题已经全部进行总结,按照章节复习即可,已经拿到了大厂offer。
原创思维导图
扫码或者微信搜 程序员的技术圈子 回复 面试 领取原创电子书和思维导图。