我惊了！CompletableFuture居然有性能问题！

先不管这几行代码是啥意思吧，反正我发现没有看到 bug 中提到的代码，只看到了 spins=SPINS ，虽然 SPINS 调用了 Runtime.getRuntime().availableProcessors() 方法，但是该字段被 static 和 final 修饰了，也就不存在 BUG 中描述的“频繁调用”了。

于是我意识到我的版本是不对的，这应该是被修复之后的代码，所以去下载了几个之前的版本。

最终在 JDK 1.8.0_202 版本中找到了这样的代码：

和前面截图的源码的差异就在于前者多了一个 SPINS 字段，把 Runtime.getRuntime().availableProcessors() 方法的返回缓存了起来。

我一定要找到这行代码的原因就是要证明这样的代码确实是在某些 JDK 版本中出现过。

好了，现在我们看一下 waitingGet 方法是干啥的。

首先，调用 get() 方法的时候，如果 result 还是 null 那么说明异步线程执行的结果还没就绪，则调用 waitingGet 方法：

而来到 waitingGet 方法，我们只关注 BUG 相关这两个分支判断：

首先把 spins 的值初始化为 -1。

然后当 result 为 null 的时候，就一直进行 while 循环。

所以，如果进入循环，第一次一定会调用 availableProcessors 方法。然后发现是多处理器的运行环境，则把 spins 置为 1<<8 ，即 256。

然后再次进行循环，走入到 spins>0 的分支判断，接着做一个随机运算，随机出来的值如果大于等于 0 ，则对 spins 进行减一操作。

只有减到 spins 为 0 的时候才会进入到后面的这些被我框起来的逻辑中：

也就是说这里就是把 spins 从 256 减到 0，且由于随机函数的存在，循环次数一定是大于 256 次的。

但是还有一个大前提，那就是每次循环的时候都会去判断循环条件是否还成立。即判断 result 是否还是 null。为 null 才会继续往下减。

所以，你说这段代码是在干什么事儿？

其实注释上已经写的很清楚了：

Use brief spin-wait on multiprocessors。

brief，这是一个四级词汇哈，得记住，要考的。就是“短暂”的意思，是一个不规则动词，其最高级是 briefest。

对了，spin 这个单词大家应该认识吧，前面忘记给大家教单词了，就一起讲了，看小黑板：

所以注释上说的就是：如果是多处理器，则使用短暂的自旋等待一下。

从 256 减到 0 的过程，就是这个“brief spin-wait”。

但是仔细一想，在自旋等待的这个过程中，availableProcessors 方法只是在第一次进入循环的时候调用了一次。

那为什么说它耗费性能呢？

是的，确实是调用 get() 方法的只调用了一次，但是你架不住 get() 方法被调用的地方多啊。

就拿 Dubbo 举例，绝大部分情况下的大家的调用方式都用的是默认的同步调用的方案。所以每一次调用都会到异步转同步这里阻塞等待结果，也就说每次都会调用一次 get() 方法，即 availableProcessors 方法就会被调用一次。

那么解决方案是什么呢？

在前面我已经给大家看了，就是把 availableProcessors 方法的返回值找个字段给缓存起来：

但是后面跟了一个“problem”，这个“problem”就是说如果我们把多处理器这个值缓存起来了，假设程序运行的过程中出现了从多处理器到单处理器的运行环境变化这个值就不准确了，虽然这是一个不太可能的变化。但是即使这个“problem”真的发生了也没有关系，它只是会导致一个小小的性能损失。

所以就出现了前面大家看到的这样的代码，这就是 “we can cache this value in a field”：

而体现到具体的代码变更是这样的：

http://cr.openjdk.java.net/~shade/8227018/webrev.01/src/share/classes/java/util/concurrent/CompletableFuture.java.udiff.html

所以，当你去看这部分源码的时候，你会看到 SPINS 字段上其实还有很长一段话，是这样的：

给大家翻译一下：

1.在 waitingGet 方法中，进行阻塞操作前，进行旋转。

2.没有必要在单处理器上进行旋转。

3.调用 Runtime.availableProcessors 方法的成本是很高的，所以在此缓存该值。但是这个值是首次初始化时可用的 CPU 的数量。如果某系统在启动时只有一个 CPU 可以用，那么 SPINS 的值会被初始化为 0，即使后面再使更多的 CPU 在线，也不会发生变化。

当你有了前面的 BUG 的描述中的铺垫之后，你就明白了为什么这里写上了这么一大段话。

有的同学就真的去翻代码，也许你看到的是这样的：

什么情况？根本就看不到 SPINS 相关的代码啊，这不是欺骗老实人吗？

你别慌啊，猴急猴急的，我这不是还没说完嘛？

我们再把目光放到图片中的这句话上：

只需要在 JDK 8 中进行这个修复即可，因为 JDK 9 和更高版本的代码都不是这样的写的了。

比如在 JDK 9 中，直接拿掉了整个 SPINS 的逻辑，不要这个短暂的自旋等待了：

http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/f3af17da360b

虽然，拿掉了这个短暂的自旋等待，但是其实也算是学习了一个骚操作。

问：怎么在不引入时间的前提下，做出一个自旋等待的效果？

答案就是被拿掉的这段代码。

但是有一说一，我第一次看到这个代码的时候我就觉得别扭。这一个短短的自旋能延长多少时间呢？

加入这个自旋，是为了稍晚一点执行后续逻辑中的 park 代码，这个稍重一点的操作。但是我觉得这个 “brief spin-wait” 的收益其实是微乎其微的。

所以我也理解为什么后续直接把这一整坨代码拿掉了。而拿掉这一坨代码的时候，其实作者并没有意识到这里有 BUG。

而这里提到的作者，其实就是 Doug Lea 老爷子。

我为什么这样说呢？

依据就在这个 BUG 链接里面提到的编号为 8227018 的 BUG 中，它们其实描述的是同一个事情：

这里面有这样一段对话，出现了 David Holmes 和 Doug Lea：

Holmes 在这里面提到了 “cache this value in a field” 的解决方案，并得到了 Doug 的同意。

Doug 说： JDK 9 已经不用 spin 了。

所以，我个人理解是 Doug 在不知道这个地方有 BUG 的情况下，拿掉了 SPIN 的逻辑。至于是出于什么考虑，我猜测是收益确实不大，且代码具有一定的迷惑性。还不如拿掉之后，理解起来直观一点。

Doug Lea 大家都耳熟能详， David Holmes 是谁呢？

《Java 并发编程实战》的作者之一，端茶就完事了。

而你要是对我以前的文章印象足够深刻，那么你会发现早在《Doug Lea在J.U.C包里面写的BUG又被网友发现了。》这篇文章里面，他就已经出现过了：

老朋友又出现了，建议铁汁们把梦幻联动打在公屏上。

到底啥原因？

---

前面噼里啪啦的说了这么大一段，核心思想其实就是 Runtime.availableProcessors 方法的调用成本高，所以在 CompletableFuture.waitingGet 方法中不应该频繁调用这个方法。

但是 availableProcessors 为什么调用成本就高了，依据是啥，得拿出来看看啊！

这一小节，就给大家看看依据是什么。

依据就在这个 BUG 描述中：

https://bugs.openjdk.java.net/browse/JDK-8227006

标题上说：在 linux 环境下，Runtime.availableProcessors 执行时间增加了 100 倍。

增加了 100 倍，肯定是有两个不同的版本的对比，那么是哪两个版本呢？

在 1.8b191 之前的 JDK 版本上，下面的示例程序可以实现每秒 400 多万次对 Runtime.availableProcessors 的调用。

但在 JDK build 1.8b191 和所有后来的主要和次要版本（包括11）上，它能实现的最大调用量是每秒4万次左右，性能下降了100倍。

这就导致了 CompletableFuture.waitingGet 的性能问题，它在一个循环中调用了 Runtime.availableProcessors。因为我们的应用程序在异步代码中表现出明显的性能问题，waitingGet 就是我们最初发现问题的地方。

测试代码是这样的：

public static void main(String[] args) throws Exception {

AtomicBoolean stop = new AtomicBoolean();

AtomicInteger count = new AtomicInteger();

new Thread(() -> {

while (!stop.get()) {

Runtime.getRuntime().availableProcessors();

count.incrementAndGet();

}

}).start();

try {

int lastCount = 0;

while (true) {

Thread.sleep(1000);

int thisCount = count.get();

System.out.printf(“%s calls/sec%n”, thisCount - lastCount);

lastCount = thisCount;

}

}

finally {

stop.set(true);

}

}

按照 BUG 提交者的描述，如果你在 64 位的 Linux 上，分别用 JDK 1.8b182 和 1.8b191 版本去跑，你会发现有近 100 倍的差异。

至于为什么有 100 倍的性能差异，一位叫做 Fairoz Matte 的老哥说他调试了一下，定位到问题出现在调用 “OSContainer::is_containerized()” 方法的时候：

而且他也定位到了问题出现的最开始的版本号是 8u191 b02，在这个版本之后的代码都会有这样的问题。

带来问题的那次版本升级干的事是改进 docker 容器检测和资源配置的使用。

所以，如果你的 JDK 8 是 8u191 b02 之前的版本，且系统调用并发非常高，那么恭喜你，有机会踩到这个坑。

然后，下面几位大佬基于这个问题给出了很多解决方案，并针对各种解决方案进行讨论。

有的解决方案，听起来就感觉很麻烦，需要编写很多的代码。

最终，大道至简，还是选择了实现起来比较简单的 cache 方案，虽然这个方案也有一点瑕疵，但是出现的概率非常低且是可以接受的。

再看get方法

---

现在我们知道了这个没有卵用的知识点之后，我们再看看为什么调用带超时时间的 get() 方法，没有这个问题。

java.util.concurrent.CompletableFuture#get(long, java.util.concurrent.TimeUnit)

首先可以看到内部调用的方法都不一样了：

有超时时间的 get() 方法，内部调用的是 timedGet 方法，入参就是超时时间。

点进 timedGet 方法就知道为什么调用带超时时间的 get() 方法没有问题了：

在代码的注释里面已经把答案给你写好了：我们故意不在这里旋转（像waitingGet那样），因为上面对 nanoTime() 的调用很像一个旋转。

可以看到在该方法内部，根本就没有对 Runtime.availableProcessors 的调用，所以也就不存在对应的问题。

现在，我们回到最开始的地方：

那么你说，下面的 asyncResult.get(Integer.MAX_VALUE, TimeUnit.MILLISECONDS) 如果我们改成 asyncResult.get() 效果还是一样的吗？

肯定是不一样的。

再说一次：Dubbo 作为开源的中间件，有可能会运行在各种不同的 JDK 版本中，且该方法是它主链路上的核心代码，对于特定的 JDK 版本来说，这个优化确实是对于性能的提升有很大的帮助。

所以写中间件还是有点意思哈。
自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数Java工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Java开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！

如果你觉得这些内容对你有帮助，可以扫码获取！！（备注Java获取）

总结

本文从基础到高级再到实战，由浅入深，把MySQL讲的清清楚楚，明明白白，这应该是我目前为止看到过最好的有关MySQL的学习笔记了，我相信如果你把这份笔记认真看完后，无论是工作中碰到的问题还是被面试官问到的问题都能迎刃而解！

MySQL50道高频面试题整理：

《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取！
盖了95%以上Java开发知识点，真正体系化！**

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！

如果你觉得这些内容对你有帮助，可以扫码获取！！（备注Java获取）

总结

本文从基础到高级再到实战，由浅入深，把MySQL讲的清清楚楚，明明白白，这应该是我目前为止看到过最好的有关MySQL的学习笔记了，我相信如果你把这份笔记认真看完后，无论是工作中碰到的问题还是被面试官问到的问题都能迎刃而解！

MySQL50道高频面试题整理：

[外链图片转存中…(img-K8k6ib2D-1713690505711)]

《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取！