对 Stream-API 的用法鼓吹够多了，但性能到底怎么样呢？，mybatis 和 spring 集成原理

2. Stream 并行迭代的性能比串行迭代和外部迭代都好。

并行迭代性能跟可利用的核数有关，上图中的并行迭代使用了全部 12 个核，为考察使用核数对性能的影响，我们专门测试了不同核数下的 S

【一线大厂Java面试题解析+核心总结学习笔记+最新架构讲解视频+实战项目源码讲义】
浏览器打开：qq.cn.hn/FTf 免费领取

tream 并行迭代效果：

分析，对于基本类型：

1. 使用 Stream 并行 API 在单核情况下性能很差，比 Stream 串行 API 的性能还差；

2. 随着使用核数的增加，Stream 并行效果逐渐变好，比使用 for 循环外部迭代的性能还好。

以上两个测试说明，对于基本类型的简单迭代，Stream 串行迭代性能更差，但多核情况下 Stream 迭代时性能较好。

实验二 对象迭代

再来看对象的迭代效果。

测试内容：找出字符串列表中最小的元素（自然顺序），对比 for 循环外部迭代和 Stream API 内部迭代性能。

测试程序 StringTest，测试结果如下图：

结果分析如下：

1. 对于对象类型 Stream 串行迭代的性能开销仍然高于外部迭代开销（1.5 倍），但差距没有基本类型那么大。

2. Stream 并行迭代的性能比串行迭代和外部迭代都好。

再来单独考察 Stream 并行迭代效果：

分析，对于对象类型：

1. 使用 Stream 并行 API 在单核情况下性能比 for 循环外部迭代差；

2. 随着使用核数的增加，Stream 并行效果逐渐变好，多核带来的效果明显。

以上两个测试说明，对于对象类型的简单迭代，Stream 串行迭代性能更差，但多核情况下 Stream 迭代时性能较好。

实验三 复杂对象归约

从实验一、二的结果来看，Stream 串行执行的效果都比外部迭代差（很多），是不是说明 Stream 真的不行了？先别下结论，我们再来考察一下更复杂的操作。

测试内容：给定订单列表，统计每个用户的总交易额。对比使用外部迭代手动实现和 Stream API 之间的性能。

我们将订单简化为<userName, price, timeStamp>构成的元组，并用Order对象来表示。测试程序 ReductionTest，测试结果如下图：

分析，对于复杂的归约操作：

1. Stream API 的性能普遍好于外部手动迭代，并行 Stream 效果更佳；

再来考察并行度对并行效果的影响，测试结果如下：

分析，对于复杂的归约操作：

1. 使用 Stream 并行归约在单核情况下性能比串行归约以及手动归约都要差，简单说就是最差的；

2. 随着使用核数的增加，Stream 并行效果逐渐变好，多核带来的效果明显。

以上两个实验说明，对于复杂的归约操作，Stream 串行归约效果好于手动归约，在多核情况下，并行归约效果更佳。我们有理由相信，对于其他复杂的操作，Stream API 也能表现出相似的性能表现。

结论

上述三个实验的结果可以总结如下：