为何Kotlin的map-filter-reduce处理大输入比Java Stream慢？

嘿，这个52倍的性能差距确实够吓人的，但别慌——问题完全不是Kotlin比Java慢这么多，而是你用了Kotlin中立即求值的集合操作，而非和Java Stream对应的惰性求值API！

核心差异：立即求值VS惰性求值 #

你写的Kotlin代码里，(0 .. 10_000_000L)是一个LongRange，它的map和filter都是立即执行的集合操作：

• 第一步map { it * it }会直接生成一个包含1000万个平方数的List<Long>
• 第二步filter { it % 2 == 0L }又会生成一个新的、包含所有偶数平方数的List<Long>
• 最后才对这个新列表求和

这中间两次大集合的内存分配、数据拷贝和GC开销，才是耗时的元凶！

而Java的LongStream是惰性求值的流：所有map、filter都是中间操作，不会生成任何中间集合，直到调用reduce时才会一次性完成遍历、计算、筛选、求和的全流程，完全没有额外的内存开销。

优化后的Kotlin写法 #

只需要把Range转换成Sequence（Kotlin的惰性流实现），就能和Java Stream达到几乎一致的性能：

fun test() {
    println((0 .. 10_000_000L).asSequence()
        .map { it * it }
        .filter { it % 2 == 0L }
        .reduce { sum, it -> sum + it })
}

另外，如果你习惯Java Stream的写法，也可以用Kotlin的JDK8流扩展，直接复用Java Stream的实现：

import kotlin.streams.asStream

fun test() {
    println((0 .. 10_000_000L).asStream()
        .map { it * it }
        .filter { it % 2 == 0L }
        .reduce { sum, it -> sum + it }
        .getAsLong())
}

优化后的性能表现 #

改成Sequence之后，你会发现Kotlin的执行速度会和Java非常接近（甚至在某些场景下略快），完全不会有几十倍的差距——毕竟本质上都是惰性流水线操作，没有中间集合的开销。

额外小贴士 #

• Kotlin中，Iterable的map、filter都是立即求值的，而Sequence的对应操作是惰性的，这是很关键的区别
• 如果处理大数据量的集合操作，优先用asSequence()转换成惰性序列，避免不必要的内存开销

放心，Kotlin的语法优势和高性能完全可以兼得，只是需要选对合适的API而已！

内容的提问来源于stack exchange，提问作者the_kaba