Java ExecutorService-有时比顺序处理慢？

Question

我正在编写一个简单的实用程序，它接受可调用任务的集合，并并行运行它们。希望所用的总时间比最长的任务所用的时间少得多。该实用程序还添加了一些错误处理逻辑--如果任何任务失败，并且该失败可以被视为“可重试”（例如超时或用户指定的异常），那么我们直接运行该任务。

我已经围绕ExecutorService实现了这个实用程序。有两个部分：

1. 向ExecutorService提交（）所有可调用任务，存储未来对象。
2. 在for循环中，get()是每个future的结果。如果出现异常，请执行“可重试”逻辑。

我编写了一些单元测试，以确保使用此实用程序比按顺序运行任务更快。对于每个测试，我会生成一定数量的可调用的，每个可调用的本质上是在一个范围内执行一个thread.sleep（）的随机时间量。我尝试了不同的超时、不同数量的任务等，该实用程序的性能似乎优于顺序执行。

但当我将它添加到需要这种实用程序的实际系统中时，我看到的结果非常多变--有时并行执行更快，有时更慢，有时更快，但仍然要比最长的单个任务花费更多的时间。

我做错了吗？我知道ExecutorService有invokeAll()，但它吞噬了底层异常。我还尝试使用CompletionService按任务完成的顺序获取任务结果，但它表现出了或多或少的相同行为。我现在正在读关于锁闩和屏障的书--这是解决这个问题的正确方向吗？

Answer 1

我编写了一些单元测试，以确保使用此实用程序比按顺序运行任务更快。对于每个测试，我会生成一定数量的可调用的，每个可调用的本质上是在一个范围内的随机时间内执行一个thread.sleep（）

是的，这肯定不是一个公平的测试，因为它既没有使用CPU也没有使用IO。我当然希望并行Hibernate比串行Hibernate运行得更快。：-）

但是当我将它添加到需要这种实用程序的实际系统中时，我看到的结果是很不一样的

对啊。线程应用程序是否比串行应用程序运行得更快，这在很大程度上取决于许多因素。特别是IO绑定的应用程序，由于受到IO通道的绑定，因此确实无法进行并发操作，因此性能不会提高。应用程序需要的处理越多，将其转换为多线程的过程就越困难。

我做错了吗？

没有更多的细节很难知道。您可以考虑使用并发运行的线程数。如果要处理大量作业，则不应使用executos.newCachedThreadPool()，而应根据体系结构的CPU数量优化newFixedSizethreadPool（...）。

您可能还想看看是否可以将IO操作隔离在几个线程中，而将处理隔离到其他线程中。比如一个输入线程读取文件，一个输出线程（或两个线程）写入数据库或其他东西。因此,对于不同类型的任务,多个大小的池可能比使用单个线程池更好。

尝试使用CompletionService按任务完成的顺序提取任务结果

如果您正在重试操作，那么使用completionservice是正确的方法。当作业完成并抛出异常（或返回失败）时，它们可以被重新启动并立即放回线程池中。我看不出有什么理由你的表现问题会是因为这个。