代码之家 › 专栏 › 技术社区 › Artem

为什么Executor接口没有将Callable作为参数的方法?

callable executorservice concurrency java

Artem · 技术社区 · 7 年前

从这个 answer 我了解到 Callable 和 Runnable

我不明白为什么 Executor 不定义采用 可赎回 :

void execute(Callable command);

在我看来,为两者创建方法是合乎逻辑的 可运行 和 可赎回 . 在里面 ExecutorService ,它是的子接口 遗嘱执行人 ,有类似的 submit() 两者的方法 可运行 和 可赎回 .

请解释一下这个设计决定,因为我在网上找不到任何解释。

3 回复 | 直到 7 年前

Andrew 7 年前

我不明白为什么 Executor 不定义采用 Callable .

一 遗嘱执行人 只有一个责任- 执行提交的任务 . 在这个抽象级别上,只使用 Runnable s不需要 ExecutorService .

为两者创建方法是合乎逻辑的 可运行 和 可赎回 .

是的,因此 遗嘱执行人服务 接口是通过扩展 遗嘱执行人 . 这个 遗嘱执行人服务 提供了显著的差异- 提供任务执行的结果。 这就是为什么 可赎回 , TimeUnit ,并添加了生命周期方法。

xs0 7 年前

我认为执行器的设计应该尽可能简单,即使用一种方法。由于execute()不提供任何获取结果的方法,因此它不接受可调用项,而只接受可运行项是有道理的。

另一方面,各种submit()函数返回Futures,它既可以用于获得结果(例如,从可调用函数中),也可以用于简单地等待执行完成。因此,同时接受可运行和可调用是有道理的。

AlexZam 7 年前

执行者运行任务。如果您想管理任务的运行方式和时间,则需要它们。执行者不收集任务结果,因此只支持 Runnable .

假设他们支持 Callable . 那么,应该如何获取结果呢? T execute(Callable<T> command) 不是选项,因为它将阻止当前线程执行。因此,它应该与一些 T getResult() 或返回 Future<T> . 为此你有 ExecutorService with方法 <T> Future<T> submit(Callable<T> task) .

推荐文章

j.doe · AWS lambda中的执行者服务

6 年前