1、stream慢？
摘抄一篇，解释分析上最为认可的，后续写代码验证：
https://blog.csdn.net/weixin_39715061/article/details/79489638
可以解释如下：
我们将for-loops与Streams进行了比较。循环本身是JIT友好的。编译器本身有了40年以上的经验，然后我们选择了循环这个JIT编译器重点优化的部分。这是所谓的某个极端：一个JIT友好的，高度优化的访问序列元素的方法。而如果是使用流的话也就意味着会在主框架内进行调用，不可避免地增加内存调用。而一个JIT编译器本身是有一个上限的，虽然大部分情况下是用不满的。因此，我们将这种情况分为JIT友好与不友好，而for-循环本身是处于JIT友好的这一边，因此它自然能够赢得这个测试，并没有神马奇怪。
我们将原始类型的序列与引用类型的序列进行了比较。这两种情况可以用缓存友好/不友好来区分。一个原始类型int的序列是非常缓存友好的，特别是当未来Java引入不可变序列的时候。而一个引用类型的序列，即使用了基于数组的，就像ArrayList的这样的存储，也是只有很小的概率进行很好地缓存。每次独立地对于序列成员的访问需要获取指针指向的地址然后获取其内容，也就意味着缓存的失效。很明显地，一个使用了int[]的for-循环肯定处在缓存友好这一边，自然与序列引用的Stream相比性能上要好上很多。
我们将元素轻量级使用与CPU密集型使用相比。更重要的是，我们将这种两个两个的比较寻找最大值的计算与Taylor相似度下寻找正弦值的计算进行了比较。在下面一个实验中，我们会以相对而言复杂一点的CPU密集型的运算为例，可能获取到这个值需要一分钟的时间。我们将此称作CPU友好或者CPU不友好的分割。一般来说，对于序列中的元素进行重量级的CPU密集型的运算的时候，也就是所谓的CPU不友好运算时，评测结果往往由CPU的运算速度决定，而对于上面讲的缓存缺失以及JIT循环的优化就变得不那么重要了。
同时，还有一篇讲多核计算的，代码可以参考：
https://blog.csdn.net/weixin_39715061/article/details/79489638
