共计 1257 个字符，预计需要花费 4 分钟才能阅读完成。
前言
最近在看 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 顶级我的项目，也有这样那样的缺点，阐明大牛们也是人，不是神，也会犯错，这让我更加有自信，来参加到开源社区中了！