我之前有一个关于解释JMH输出的问题，这个问题得到了大部分的回答，但我用另一个相关问题更新了这个问题，但最好把它作为一个单独的问题。
这是最初的问题：验证简单的 for/lambda 比较的 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"测试的性能。
我看到在"短"列表中，流性能是"for"性能的 14%。 对于中等名单，它是29%。 对于较长的名单，它是78%。到目前为止，趋势是我所期望的。 但是，对于长名单，它是 11%。 出于某种原因，与"for"相比，300k 而不是 300 的列表大小导致流的性能下降。
我想知道是否有人可以证实这样的结果，以及他们是否对为什么会发生这种情况有任何想法。
我在带有Java 7的Win8笔记本电脑上运行它。
嗯，与"for 循环"相比，流是 Java 的一个全新补充，JIT 编译器并没有对它们进行任何复杂的优化，就像它对数组或集合的循环所做的那样。