Java 7 fork/join 是否保证在单独的 CPU 中执行线程答案

【问题标题】：Does Java 7 fork/join guarantees executing thread in seperate CPUJava 7 fork/join 是否保证在单独的 CPU 中执行线程
【发布时间】：2014-04-29 22:37:39
【问题描述】：

最近，我开始了解 Java 7 fork/join 框架 - 我了解到它可以用于解决类似分而治之的问题。

我的问题是，框架是否保证在不同的 CPU 上执行线程？或者是否可以指示我使用并发包类创建的线程在我的服务器中可用的单独 CPU 上运行？

【问题讨论】：

标签： java multithreading fork-join

【解决方案1】：

它将建立在标准的 JVM 并发原语之上，在这种情况下，它们将（最终）被调度到真正的操作系统线程上。您不能保证您的操作系统调度程序会将线程调度到单独的 CPU 上，尽管在大多数情况下很有可能。

试图猜测并发调度程序在运行时会做什么是一个非常糟糕的主意。假设您可以使用的 CPU 数量不超过活动线程的数量，并且除非您尝试执行特定类型的非常低级别的操作，否则不要尝试事后猜测运行时行为优化。

【讨论】：

谢谢吉安。以前我使用基本线程从数据库加载一些东西，我在单独的线程中做到了。我猜用 F/J 实现这一点不会带来额外的好处？
FJ 不是用于基于 I/O 的任务，而是用于 CPU 受限算法。所以经验法则可能是：I/O 用于线程，CPU 使用 F/J
F/J 不太可能提供特定的性能优势，但它可能允许您以更易于理解、优化或推理的方式构建并发代码。
Gian，部分不同意。如果用于divide et impera CPU 有界算法，FJ 为您提供了在多个线程上拆分工作的好处，从而从并行执行中获益。当然，如果在正确的假设下使用。
在使用线程之外，这会给您带来额外的性能优势吗？当然，并行化在许多情况下会提供性能优势，但在所有其他条件相同的情况下，fork/join 不太可能客观地提供比线程（或反之亦然）更好的性能。

【解决方案2】：

至少它会尽力而为。 fork/join 框架旨在利用多个处理器。默认情况下，创建 ForkJoinPool 时工作线程的数量等于处理器的数量。

【讨论】：

“fork/join 框架旨在利用多个处理器” - 使用基本线程怎么样？如果我使用基本线程或线程池，它会利用多处理器吗？
基本线程有点难编程。使用 Fork/Join，您可以拥有简单的原语，并且所有线程工作都在幕后完成。您只需创建 ForkJoinPool 并扩展 RecursiveTask 类
@trapo，我担心调度程序是否应该在单独的 CPU 上运行基本线程，我的意思是从这个意义上说（在单个 CPU 上调度线程）基本线程与 F/ J?

【解决方案3】：

框架是否保证在不同的 CPU 上执行线程？

没有。没有保证。

或者是否可以指示我使用并发包类创建的线程在我的服务器中可用的单独 CPU 上运行？

不使用标准 Java 库。从理论上讲，如果您愿意在 JVM 的本机层中进行挖掘，任何事情都是可能的（在操作系统允许的范围内）。但是你会承担很多不必要的工作/痛苦。

我的建议：

您可能不需要那种级别的控制。 (IMO) 本机线程调度程序的默认行为很可能“足够好”以实现令人满意的性能。
如果您真的需要这种级别的控制，最好使用不同的编程语言；即您可以直接与主机操作系统的本机线程调度程序交互的地方。您甚至可能需要不同的操作系统...

【讨论】：

所以说我的多线程应用程序本质上不是分而治之，或者它不做工作窃取（这个概念我完全不清楚）——用 F/J 做会有没有比使用基本线程做的额外优势？
工作窃取意味着一个 RecursiveAction 由一个线程分配，并且可以在 ForkJoinPool 的另一个空闲线程上执行，将该操作从第一个线程的私有队列移动到第一个线程的队列其他线程。
谢谢@trapo，你能提供一些使用工作窃取的代码吗？
是的，我自己的问题（以及关于 SO 的回答）：stackoverflow.com/questions/14076890/… 请注意，您不要使用偷工减料，但请注意。
如果你对 F/J 感兴趣，我在上面写了一个小帖子。该帖子是意大利语的，但最后您可以找到有关该主题的有用链接列表：cosenonjaviste.it/…。您还可以尝试一门课程，展示如何将任务从一个线程移动到另一个线程。