我有以下包装器公开awaitTermination的{{1}}方法
ExecutorService典型输入为500毫秒。用户理解这些时间是近似值。
我对public class AwaitableTermination {
protected final ExecutorService executorService;
public AwaitableTermination(ExecutorService executorService) {
this.executorService = executorService;
}
public boolean awaitTermination(long timeout) throws InterruptedException {
return executorService.awaitTermination(timeout, TimeUnit.MILLISECONDS);
}
}
类的新要求扩展了CompositeAwaitableTermination，其中包含AwaitableTermination个对象的列表。如果所有ExecutorService个对象在输入时间范围内终止，则awaitTermination应返回true，否则ExecutorService。
我可以在其自己的线程中false awaitTermination，但这似乎非常浪费，更不用说不精确了（不能保证所有线程都会及时执行）。
一种可能的单线程方法是迭代ExecutorService并根据每个对象减少超时
ExecutorServices然而，这种方法让我感到非常容易出错，因为private final List<ExecutorService> services;
public boolean awaitTermination(long timeout) throws InterruptedException {
Queue<ExecutorService> queue = new ArrayDeque<>(services);
long start = System.currentTimeMillis();
boolean result = true;
ExecutorService service = null;
while(result && (service = queue.poll()) != null) {
long currentTimeout = timeout - (System.currentTimeMillis() - start);
if(currentTimeout > 0) {
result = service.awaitTermination(currentTimeout, TimeUnit.MILLISECONDS);
} else {
result = false;
}
}
return result;
}
的大集合（目前我预计ExecutorServices集合中的对象不超过4个，但我不是我不得不依赖这个假设）。是否有更精确/更优雅的方式来做到这一点？
答案 0 :(得分：1)
我发现此代码没有问题。
如果你有大集合（比如100k +）的ExecutorService，你应该更关心线程的实际数量！
awaitTermination如果服务已经关闭或者没有任务正在等待，那么根本就没有时间，如果你有很多ExecutorService运行，很可能就是这种情况，否则你的系统应该已经受到影响了。因此，即使对于大型集合，此代码也不应该有任何问题。