当前位置: 移动技术网 > IT编程>开发语言>Java > Java 8并行流的性能陷阱

Java 8并行流的性能陷阱

2019年08月15日  | 移动技术网IT编程  | 我要评论
并行化流被分成多个块,每个块独立处理,结果在最后汇总。 CPU密集型代码如下: countPrimes 计算1到最大值之间的素数的数量。数字流由range方法创建,切换到并行模式,过滤掉非素数,剩余的计算总数。由于isPrime 方法极其无效且占用大量CPU,我们可以利用并行化并利用所有可用的CPU ...

并行化流被分成多个块,每个块独立处理,结果在最后汇总。

cpu密集型代码如下:

 

private long countprimes(int max) {
    return range(1, max).parallel().filter(this::isprime).count();
}
private boolean isprime(long n) {
    return n > 1 && rangeclosed(2, (long) sqrt(n)).nonematch(divisor -> n % divisor == 0);
}

 countprimes 计算1到最大值之间的素数的数量。数字流由range方法创建,切换到并行模式,过滤掉非素数,剩余的计算总数。由于isprime 方法极其无效且占用大量cpu,我们可以利用并行化并利用所有可用的cpu内核。

 

我们来看另一个例子:

 

private list<stockinfo> getstockinfo(stream<string> symbols) {
     return symbols.parallel()
            .map(this::getstockinfo) //slow network operation
            .collect(tolist());
}

输入是一个股票代码列表,我们必须调用慢速网络操作来获取有关股票的一些细节。在这里,我们不处理cpu密集型操作,但我们也可以利用并行化。并行执行多个网络请求是个好主意。同样,并行流的一个很好的任务,你同意吗?

 

如果您这样做,请再次查看上一个示例。有一个很大的错误。你看到了吗?问题是所有并行流都使用。如果提交长时间运行的任务,则会有效地阻塞池中的所有线程。因此,您将阻塞使用并行流的所有其他任务。

 

想象一下servlet环境,当一个请求调用时getstockinfo() ,另一个请求调用  countprimes()。即使每个都需要不同的资源,也会阻止另一个。更糟糕的是,你不能为并行流指定线程池; 整个类加载器必须使用相同的。

 

让我们在下面的例子中说明它:

 

private void run() throws interruptedexception {
 executorservice es = executors.newcachedthreadpool();
 // simulating multiple threads in the system
 // if one of them is executing a long-running task.
 // some of the other threads/tasks are waiting
 // for it to finish
 es.execute(() -> countprimes(max, 1000));
 //incorrect task
 es.execute(() -> countprimes(max, 0));
 es.execute(() -> countprimes(max, 0));
 es.execute(() -> countprimes(max, 0));
 es.execute(() -> countprimes(max, 0));
 es.execute(() -> countprimes(max, 0));
 es.shutdown();
 es.awaittermination(60, timeunit.seconds);
}
private void countprimes(int max, int delay) {
  system.out.println( range(1, max).parallel() .filter(this::isprime).peek(i -> sleep(delay)).count() );

}

 

在这里,我们模拟系统中的六个线程。所有这些都在执行cpu密集型任务,第一个被“暂停”,在它找到素数后就睡了一秒钟。这只是一个人为的例子; 你可以想象一个被卡住或执行阻塞操作的线程。

 

问题是:执行此代码时会发生什么?我们有六个任务; 其中一个将需要一整天才能完成,其余的应该更快完成。毫不奇怪,每次执行代码时,都会得到不同的结果。你想在生产系统中有这样的行为吗?一个杜塞的任务取消了应用程序的其余部分?我猜不会。

 

关于如何确保永远不会发生这样的事情,只有两种选择。第一个是确保提交到公共fork-join池的所有任务都不会卡,必须在合理的时间内完成。但这说起来容易做起来难,尤其是在复杂的应用程序中。

 

另一种选择是不使用并行流,并等到oracle允许我们指定用于并行流的线程池。

如您对本文有疑问或者有任何想说的,请 点击进行留言回复,万千网友为您解惑!

相关文章:

验证码:
移动技术网