就性能而言，在java中使用runnable而不是callable是否更可取？ [关闭]答案

【问题标题】：Is it preferable to use runnable instead of callable in java, in terms of performance? [closed]就性能而言，在java中使用runnable而不是callable是否更可取？ [关闭]
【发布时间】：2013-06-21 18:34:14
【问题描述】：

我刚开始学习一门函数式语言 (Scala)，其中一个声明/建议是，在执行多线程时，“您应该尝试使用 react 而不是 recieve”方法。为了清楚起见，react 不会返回任何值，但recieve 会。他们有自己的理由支持这项建议。由于 Scala 在 JVM 上工作。让我好奇的是，使用 Callable 是否比在 Java 中使用 Runnable 更昂贵？

有没有人在这方面有相同或 cmets 的经验？

【问题讨论】：

标签： java multithreading performance scala

【解决方案1】：

Runnable 和 Callback 具有与 Interfaces 相同的“性能”。

两个接口都有slight API differences——必须使用与消费API兼容的类型；就是这样。

这与 Scala 或 Actors 中的react vs. recieve 无关；问题框本身进入了错误的角落。

【讨论】：

不确定这个答案的意图是什么。问题在于 Callable 与 Java 中的 Runnable 相比是否有一些性能差异。我不是在比较 Scala 和 Java 或它们的 api。
@Prateek 目的是回答这个问题，它确实做到了。 Runnable 和 Callback 具有相同的“性能”，因为它们只是接口。 - 使用引号表示接口没有绩效指标，因为它们只是签名合同；使用或使用接口的代码可能具有不同的性能特征。相关链接解释 1）不同的接口合约（没有提到“性能”）和； 2）反应/接收（这是一个不同且不相关的主题）。雷克斯花时间为你拼出来。
没有人会想到在作家会议上有人会争论 C 在 B 之后。

【解决方案2】：

嗯，你真的在这里混合了不同的概念。

使用react 而不是receive 的原因是每个带有receive 的actor 都需要自己的线程。所以每个演员都有一个线程。另一方面，react 由线程池处理，这些线程将在该参与者上运行该消息，然后继续处理下一个参与者和消息。（这实际上只允许你做出反应——你不能等待一定的时间。）

另一方面，Runnable 和 Callable 接口只是在 Java 中打包代码的方法，具体取决于您是希望它做一些事情 (Runnable) 还是返回一个值 (Callable) .接口本身在性能上没有任何差异，但是为了将 Callable 返回值返回给您，还需要做一些额外的事情，所以如果您可以用任何一种方式编写它，您可能会更好使用只需要Runnable 的东西。（实际上，这可能意味着启动一个线程而不是一个未来。）但是实现细节非常重要，以至于您不能仅根据接口提出任何一般性建议。你需要知道接口在你调用的实际类中是如何被实际使用的。

【讨论】：