乐趣区

关于java:什么Dubbo竟然抄袭Netty源码

前言

最近在看 dubbo 源码的时候,忽然发现一个乏味的事件,dubbo 有一小部分代码是一成不变的剽窃 Netty 代码。间接上图:
dubbo 源码:

Netty 源码:

能够看到,Dubbo 只是改了个类名(FastThreadLocal -> InternalThreadLocal),连正文都照搬过去了!并美其名曰“借鉴”Netty 的设计思路。的确,代码人的事件怎么能叫剽窃呢?嘿嘿。

正题

不过话说回来,尽管是剽窃,但也正阐明了 Netty 的 FastThreadLocal 设计思路十分好,才会让 Dubbo 的开发者将它也引入了 Dubbo 外部。上面咱们就来看看 FastThreadLocal 的设计思路和实现原理吧。

设计思路

从正文上能够看到,FastThreadLocal 采纳数组下标的形式,代替了 JDK 原生的 hash code + hash table 的形式,尽管改变不大,但在频繁拜访的场景下,也能晋升性能。
它有个应用前提,那就是咱们的线程 Thread 必须是 FastThreadLocalThread 的实现类或子类,因而 Netty 外部的默认 ThreadFactory 创立的都是 FastThreadLocalThread 类型,如果是其余 Thread 类型,会进化到 JDK 的 ThreadLocal。

实现原理

(ps: 胃病犯了,下次补充上,有趣味的童鞋能够本人去翻看下,有急躁的童鞋能够点个关注,下次肯定更新!对,下次肯定!嘻嘻)

小插曲

另外我在看 Dubbo 的 SPI 局部源码时,还发现了一件乏味的事件,有位热心的开源贡献者给 Dubbo 提交了 PR,说是 JDK1.8 的 ConcurrentHashMap#computeIfAbsent() 办法有 bug,就把它换成了 putIfAbsent(),并被 Dubbo 的 commiter review 通过并合入了。PR 链接:https://github.com/apache/dub…

这位开源贡献者还把这个 jdk 官网 bug 的记录列表收回来了
https://bugs.openjdk.java.net…

带着好奇心,我也关上了这个 bug 链接,说的是如果在 computeIfAbsent() 办法外面递归调用 computeIfAbsent() 的话,有几率呈现死循环 bug,这个几率指的是哈希碰撞的时候。具体看 bug 形容吧:

死循环样例代码:

这个 bug 只有在递归调用的时候才有几率呈现死循环,并且 ConcurrentHashMap 的作者 Doug Lea 巨匠,在 JDK1.9 版本的解决办法也只是在检测到递归调用的时候抛出异样,阐明不举荐用户递归调用:


也就是说,只有咱们不递归调用 computeIfAbsent,就不会呈现死循环 bug, 显然 dubbo 这里没有违反这公约定,天然不会呈现死循环 bug,挺好奇过后 commiter 是怎么 review 通过并 merge 的呢?

这两件事,让我领会到,哪怕是 Dubbo 这样出名的 Apache 顶级我的项目,也有这样那样的缺点,阐明大牛们也是人,不是神,也会犯错,这让我更加有自信,来参加到开源社区中了!

退出移动版