为什么java流的性能会随着相对较大的工作量而下降；至于；环

我之前有一个关于解释JMH输出的问题，这个问题大部分都得到了回答，但我用另一个相关问题更新了这个问题，但最好将这个问题作为一个单独的问题

这是原始问题：

我的问题与特定“工作”级别的流的性能有关。以下摘自上一个问题的结果说明了我的疑问：

Benchmark                                            Mode  Cnt          Score         Error  Units
MyBenchmark.shortLengthConstantSizeFor              thrpt  200  132278188.475 ± 1132184.820  ops/s
MyBenchmark.shortLengthConstantSizeLambda           thrpt  200   18750818.019 ±  171239.562  ops/s
MyBenchmark.mediumLengthConstantSizeFor             thrpt  200   55447999.297 ±  277442.812  ops/s
MyBenchmark.mediumLengthConstantSizeLambda          thrpt  200   15925281.039 ±   65707.093  ops/s
MyBenchmark.longerLengthConstantSizeFor             thrpt  200    3551842.518 ±   42612.744  ops/s
MyBenchmark.longerLengthConstantSizeLambda          thrpt  200    2791292.093 ±   12207.302  ops/s
MyBenchmark.longLengthConstantSizeFor               thrpt  200       2984.554 ±      57.557  ops/s
MyBenchmark.longLengthConstantSizeLambda            thrpt  200        331.741 ±       2.196  ops/s

当测试从较短的列表移动到较长的列表时，我期望流测试的性能应该接近“for”测试的性能

我在“short”列表中看到，流性能是“for”性能的14%。中等收入者占29%。在较长的名单中，这一比例为78%。到目前为止，这一趋势正是我所期待的。然而，在长长的名单中，这一比例为11%。由于某种原因，与“For”相比，300k的列表大小（而不是300）导致流的性能下降

我想知道是否有人能证实这样的结果，以及他们是否有关于为什么会发生这种情况的想法

---

我在一台装有Java 8的Win7笔记本电脑上运行它。

与“for循环”相比，streams是Java的一个全新添加，JIT编译器并没有对它们进行任何复杂的优化，就像它对数组或集合上的循环所做的那样。

相关问题：@DanielWiddis引人入胜的阅读，感谢您的发布