求求你们了,别再乱用 parallelStream 了,速度竟然比 Stream 还要慢!!

Posted Java技术栈

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了求求你们了,别再乱用 parallelStream 了,速度竟然比 Stream 还要慢!!相关的知识,希望对你有一定的参考价值。

parallelStream 一定更快吗?

大家都知道 Stream 分为顺序流和并行流:

  • stream(顺序流)
  • parallelStream(并行流)

它们最大的区别就是 parallelStream 支持并行化处理,所以效率较 stream(顺序流)肯定是要更快的。这篇不会介绍 Stream 基础,Stream 系列我之前写过一个专题了,不懂的关注公众号Java技术栈,然后在公众号 Java 教程菜单中阅读。

然而你确定 parallelStream 一定要更快吗?

栈长写了一段排序的示例,分别用 stream 和 parallelStream,对 100 ~ 10000000 条数据的集合进行排序,来看下执行效率究竟如何!

顺序流排序:

/**
 * 顺序流排序
 * @author: 栈长
 * @from: 公众号Java技术栈
 */
private static void streamSort() 
    long start = System.currentTimeMillis();
    List<SortTest.User> list = new ArrayList<>(LIST);

    list.stream().sorted(SortTest.User::compareAge).collect(Collectors.toList());

    System.out.println("\\nList size: " + list.size() + " Stream.sorted: " + (System.currentTimeMillis() - start));

并行流排序:

/**
 * 并行流排序
 * @author: 栈长
 * @from: 公众号Java技术栈
 */
private static void parallelStreamSort() 
    long start = System.currentTimeMillis();
    List<SortTest.User> list = new ArrayList<>(LIST);

    list.parallelStream().sorted(SortTest.User::compareAge).collect(Collectors.toList());

    System.out.println("List size: " + list.size() + " ParallelStream.sorted: " + (System.currentTimeMillis() - start));

本文所有完整示例源代码已经上传:

https://github.com/javastacks/javastack

执行结果如下:

List size: 10000000 Stream.sorted: 202 List size: 10000000 ParallelStream.sorted: 402

List size: 1000000 Stream.sorted: 53 List size: 1000000 ParallelStream.sorted: 15

List size: 100000 Stream.sorted: 1 List size: 100000 ParallelStream.sorted: 2

List size: 10000 Stream.sorted: 0 List size: 10000 ParallelStream.sorted: 1

List size: 1000 Stream.sorted: 0 List size: 1000 ParallelStream.sorted: 1

List size: 100 Stream.sorted: 0 List size: 100 ParallelStream.sorted: 0

在 100000 以下是没什么区别的;

在 1000000 左右 ParallelStream 虽然领先 Stream,但也不是绝对每次都领先,经过不断测试,这个数据量区间的测试两者会互相领先;

在 10000000 左右就很稳定了,ParallelStream 几乎比 Stream 慢了 2 倍!

现在你可能会有疑问了,为什么会这样?

栈长起初也有疑问,并行流(ParallelStream)怎么会比顺序流(Stream)还要慢。。

其实我后面想想也就明白了,并行流(ParallelStream)的背后其实是 Java7 开始支持的 Fork/Join,即把一个大任务拆分成 N 个小任务,然后最终合并各个子任务的结果,所以对于子任务线程的拆分、创建、结果合并等操作都需要不少的开销,特别是线程的创建。

所以这种不耗时的简单排序操作事实上是不适用于并行流(ParallelStream)的,它所带来的线程创建的损耗可能还会比顺序流(Stream)还要更慢。

最新 Java 8+ 面试题也都整理好了,点击Java面试库小程序在线刷题。

什么时候用 ParallelStream?

既然使用 Fork/Join 是会有损耗的,那对于单条数据的处理的时间最好是理论上要超过用并行流(ParallelStream)本身的损耗,这种情况下就比较合适。

也就是说,如果对于流中的每条数据的处理比较费时间,并且没有顺序要求,这种场景下用并行流(ParallelStream)会更快,更合适。

来看下面这个示例:

顺序流数据处理:

/**
 * 顺序流数据处理
 * @author: 栈长
 * @from: 公众号Java技术栈
 */
private static void streamProcess() 
    long start = System.currentTimeMillis();
    List<SortTest.User> list = new ArrayList<>(LIST);

    list.stream().map(StreamSpeedTest::process).collect(Collectors.toList());

    System.out.println("\\nList size: " + list.size() + " Stream process: " + (System.currentTimeMillis() - start));

并行流数据处理:

/**
 * 并行流数据处理
 * @author: 栈长
 * @from: 公众号Java技术栈
 */
private static void parallelStreamProcess() 
    long start = System.currentTimeMillis();
    List<SortTest.User> list = new ArrayList<>(LIST);

    list.parallelStream().map(StreamSpeedTest::process).collect(Collectors.toList());

    System.out.println("List size: " + list.size() + " ParallelStream process: " + (System.currentTimeMillis() - start));

数据处理:

/**
 * 数据处理
 * @author: 栈长
 * @from: 公众号Java技术栈
 */
private static SortTest.User process(SortTest.User user) 
    try 
        user.setName(user.getName() + ": process");
        Thread.sleep(5);
     catch (InterruptedException e) 
        e.printStackTrace();
    
    return user;

注意: 这里加了个休眠 5 毫秒,为了体现真实的处理数据耗时。

本文所有完整示例源代码已经上传:

https://github.com/javastacks/javastack

并行流排序:

List size: 1000 Stream process: 5750 List size: 1000 ParallelStream process: 745

List size: 100 Stream process: 566 List size: 100 ParallelStream process: 77

结果很明显了,不管测试多少次,并行流(ParallelStream)的处理速度都要比顺序流(Stream)要快几倍!!我这里只测试了 100 和 1000 条数据,因为 10000 条以上的数据用顺序流(Stream)可能要等非常久。

而且我程序中的处理逻辑只休眠了 5 毫秒,如果实际处理单条数据的耗时要比这个更长,那并行流(ParallelStream)的处理效率还会更明显。

总结

稍微总结下:

  • stream: 适用于避免线程安全问题、要求顺序执行、数据处理简单不耗时的任务;
  • parallelStream: 适用于不存在线程安全问题、不需要顺序性执行、数据处理比较耗时的任务;

所以,你学废了吗?赶紧发给身边的同事看看吧,别再乱用 parallelStream 了!用的不好,存在线程安全问题不说,效率上可能还会适得其反。

大家如果对 Java 8 新增的知识点(Lambda、Stream、函数式接口等)还不会用的可以关注公众号:Java技术栈,在 Java 教程菜单中阅读,Java 8+ 系列教程我都写了一堆了。

本文所有完整示例源代码已经上传:

https://github.com/javastacks/javastack

欢迎 Star 学习,后面 Java 示例都会在这上面提供!

好了,今天的分享就到这里了,后面栈长会分享更多好玩的 Java 技术和最新的技术资讯,关注公众号Java技术栈第一时间推送,我也将主流 Java 面试题和参考答案都整理好了,在公众号后台回复关键字 "面试" 进行刷题。

最后,觉得我的文章对你用收获的话,动动小手,给个在看、转发,原创不易,栈长需要你的鼓励。

版权声明: 本文系公众号 "Java技术栈" 原创,转载、引用本文内容请注明出处,抄袭、洗稿一律投诉侵权,后果自负,并保留追究其法律责任的权利。

近期热文推荐:

1.1,000+ 道 Java面试题及答案整理(2022最新版)

2.劲爆!Java 协程要来了。。。

3.Spring Boot 2.x 教程,太全了!

4.别再写满屏的爆爆爆炸类了,试试装饰器模式,这才是优雅的方式!!

5.《Java开发手册(嵩山版)》最新发布,速速下载!

觉得不错,别忘了随手点赞+转发哦!

以上是关于求求你们了,别再乱用 parallelStream 了,速度竟然比 Stream 还要慢!!的主要内容,如果未能解决你的问题,请参考以下文章

求求你们了,MyBatis 批量插入别再乱用 foreach 了,5000 条数据花了 14 分钟。。

求求你们了,MyBatis 批量插入别再乱用 foreach 了,5000 条数据花了 14 分钟。。...

别再乱用 Prometheus 联邦了,分享一个 Prometheus 高可用新方案

别再乱用了,这才是 @Validated 和 @Valid 的真正区别

别再乱用了,这才是 @Validated 和 @Valid 的真正区别!!!

别再乱用了,这才是 @Validated 和 @Valid 的真正区别!!!