Thread 在这里比 Executor 更受青睐吗？答案

【问题标题】：Is Thread to be favoured over Executor here?Thread 在这里比 Executor 更受青睐吗？
【发布时间】：2015-02-11 21:42:05
【问题描述】：

据我了解，Executors 帮助处理 runnables 的执行。例如。当我有几个工作线程完成它们的工作然后终止时，我会选择使用执行器。执行器将处理执行工作线程所需的线程的创建和终止。

但是现在我面临另一种情况。固定数量的类/对象应封装它们自己的线程。因此，线程在创建这些对象时启动，并且线程将在这些对象的整个生命周期内继续运行。反过来，少数对象是在程序开始时创建的，并且在整个运行时都存在。我想在这种情况下线程比执行程序更可取，但是当我阅读互联网时，每个人似乎都建议在任何可能的情况下使用执行程序而不是线程。

有人可以告诉我是否要在这里选择 Executors 或 Threads，为什么？

谢谢

【问题讨论】：

这些线程在其生命周期中会做什么？他们会 100% 忙于计算 pi 的小数点，还是会闲置直到与之交互？
视情况而定......其中一些将有大约 50% 的空闲时间，其他只有大约 10%
...还有一些人会 100% 忙于计算树的哈希值。

标签： java concurrency executorservice

【解决方案1】：

你有些混淆了。 Executor 只是一个接口。 Thread 是一个核心类。没有什么直接暗示Executor 实现在单独的线程中执行任务。

阅读 JavaDoc 的前几行。

Executor

因此，如果您想要完全控制，只需使用 Thread 并自己做事。

【讨论】：

他大概在考虑ExecutorServices和ThreadPoolExecutor之类的Executors。
@aioobe 是的，我知道。但这只是一种思考方式。
很抱歉让您感到困惑。但是，正如 aioobe 所说，我指的是 ExecutorServices。

【解决方案2】：

在不了解上下文的情况下，很难给出一个好的答案，但一般来说，我会说需要使用Thread 的情况很少而且相差甚远。如果您开始尝试使用synchronized“手动”同步您的程序，我敢打赌事情会很快失控。（更不用说调试代码有多难了。）

我上次使用线程是在我想在后台录制一些音频时。这是一种“开始”/“停止”的事情，而不是“面向任务的”。（我尝试了很长时间并努力寻找一个可以为我封装的音频库但失败了。）

如果您选择使用线程解决方案，我建议您尝试将线程的范围限制为仅在关联对象内执行。这将尽可能避免强迫您在整个代码中考虑happens-before关系、线程安全的值发布等。

【讨论】：

“如果你开始尝试使用同步来“手动”同步你的程序，我会说你真的如履薄冰”为什么会这样？有任何参考支持吗？
Java 内存模型非常复杂，并且在关系迅速失控之前就发生了思考。在几乎所有情况下，您都应该尝试使用 java.util.concurrent 提供的类来处理更高级别的抽象。
@user3187049 恕我直言，继续使用它，先学习低级的东西。然后你会对更高层次的东西感到很舒服。 :)
简而言之，您要么使用Thread，因为您正在实施自定义执行服务；或使用现有的实现。很少有情况需要自定义实现。
也许你应该描述你真正需要的东西，因为我觉得你正在为你的问题创建错误的解决方案

【解决方案3】：

ExecutorService 可以有线程池

它优化了性能，因为创建线程很昂贵。

ExecutorService 有生命周期控制

提供shutdown()、shutdownNow()等。

ExecutorService 灵活

您可以调用各种行为：自定义ThreadFactory、设置线程池大小、延迟行为ScheduledThreadPoolExecutor 等...

【讨论】：