为什么我不能用 BlockingQueue<Callable> 实例化 ThreadPoolExecutor；为什么只有 BlockingQueue<Runnable>？答案

【问题标题】：Why can't i instantiate ThreadPoolExecutor with BlockingQueue<Callable>; why only BlockingQueue<Runnable>?为什么我不能用 BlockingQueue<Callable> 实例化 ThreadPoolExecutor；为什么只有 BlockingQueue<Runnable>？
【发布时间】：2013-08-09 18:41:08
【问题描述】：

我的理解是callable是在1.5中加入的，runnable接口保持原样是为了防止世界末日。为什么我不能实例化 ThreadPoolExecutor(core, max, tu, unit, new BlockingQueue<Callable>()) - 为什么队列必须只取可运行？在内部，如果我要提交、invokeAll、invokeAny 可调用对象，这应该没问题吧？另外，shutDownNow() 会返回一个可调用列表吗？

【问题讨论】：

因为您不能将Runnables 添加到Callables 的队列中。

标签： java jdk1.5 threadpoolexecutor

【解决方案1】：

您可以提交Callables，但它们在内部被包装为Runnables（实际上是FutureTasks，它实现了Runnable）。 shutDownNow() 只会返回 Runnables，就像它在锡上所说的那样。

如果您想获取尚未运行的 Callables 列表，您需要自己跟踪它们（例如，保留它们的列表并让它们负责将自己从列表中删除当他们被调用时。）

【讨论】：

【解决方案2】：

作为更一般的答案，您不能通过更改类型参数来影响 Java 程序的运行时行为。没有if 分支可以根据类型参数重新路由。如果您发现自己处于希望从 API 获得不同行为的情况，请不要在类型参数的选择中寻找解决方案。

在这种特殊情况下，Runnable 是一种更通用的对象类型：它是 Executor 内部可以提交给线程的工作单元。例如，Runnable 可以包含调用Callable 并将其结果保存在某处的代码。

【讨论】：

感谢您的指导。为了更好地理解，您建议我使用包装可调用对象的可运行对象（它将在原始可运行对象的提交者之外的其他地方吐出结果？我该如何获取这个[必须有很多方法，具体取决于环境） ] 一般？这种读取结果的能力将决定什么有效，什么无效，我认为这更重要，不过，我仍然担心此时执行的开始）。
我想我已经意识到您的困惑：您认为传入的队列是 Executor 的公共 API 的一部分，您可以在 Executor 运行时检查内容运行等。但实际上，您传递的是 Executor 内部的构建块，构造函数接受它的原因是因为队列实现的细节会影响 Executor 行为的重要整体方面。在正常的 Executor 操作期间，您不应该以任何方式接触该队列。

【解决方案3】：

由于类型擦除，不能同时使用BlockingQueue<Callable<T>> 和BlockingQueue<Runnable>；两个重载都将具有相同的原始类型 BlockingQueue，因此会发生冲突。

不过，我不知道您会如何处理提交给执行者的Callables 列表。你会如何处理他们的结果？它会去哪里？

听起来您想要Future<T>。您可以使用invokeAll 提交Callable<T>s 的集合，然后您将取回Future<T>s 的集合，一旦它们可用，您就可以从中获取值。

【讨论】：

嗯，我想跟踪哪些可调用对象没有执行。假设我提交/invokeAll/invokeAny 一个可调用列表，在我可以遍历所有它们的 future.get 之前，或者甚至在我开始迭代之前，应用程序已关闭，我们发出了一个shutDownNow，我可以期待一个列表甚至没有开始运行的那些？我想答案是否定的，正如@david-moles 所述
@SaadShakil 您可以遍历从invokeAll 获得的List<Future<T>>s，并检查每个isTerminate()。如果不详细了解用例，很难给出更具体的建议。