JAVA并行流的性能“陷阱”

从java8开始,并行编程变得很容易,通过并行流(parallelStream),可以很轻松的实现多线程并行处理。但是,这里面有个性能“陷阱”,如果不注意,使用并行流的效果反而更差,这个陷阱是什么呢?

这个陷阱就是,并行流默认都是用同一个默认的ForkJoinPool,这个ForkJoinPool的线程数和CPU的核心数相同。如果是计算密集型的操作,直接使用是没有问题的,因为这个ForkJoinPool会将所有的CPU打满,系统资源是没有浪费的,但是,如果其中还有IO操作或等待操作,这个默认的ForkJoinPool只能消耗一部分CPU,而另外的并行流因为获取不到该ForkJoinPool的使用权,性能将大大降低。可见,默认的ForkJoinPool**必须只能**处理计算密集型的任务。

那么,对应非计算密集型的任务,改怎么处理呢? 这就需要我们使用自己创建的ForkJoinPool来执行任务,下面给出实例代码:

    ForkJoinPool forkJoinPool = new ForkJoinPool(8); 
    forkJoinPool.submit(()->{
        tasks.parallelStream().forEach(t->{
            try {
                String gdsstatus=transactionService.GetTransInfo(url, t.getTask_id());
                checkStatus(t.getTask_id(),t.getTask_status(),gdsstatus);
            } catch (Exception e) {
                System.out.println("EXCEPTION OCCOR IN TASK:"+t.getTask_id());
                e.printStackTrace();
            }

            System.out.println("NO:"+count.getAndIncrement()+" is done");

        });
    });
  • 0
    点赞
  • 10
    收藏
    觉得还不错? 一键收藏
  • 4
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 4
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值