问题标签 [fork-join]

如果我有 2 个 CPU 并为 fork / join 框架安排 1000 个任务来处理，这些任务一次最多执行 2 个，还是会在同一个 CPU 上并行执行更多任务？（比如说，也许一个任务正在等待 I/O，在这种情况下 CPU 会变得空闲，另一个线程可以运行）

我正在使用 Java 7 并发和并行功能 - Fork/Join Framework。

我正在尝试显示给定路径下所有目录的列表。有人可以告诉我这是否正确吗？

这是我的主要课程 - 启动任务的 JoinForkExample

这是我的实际任务

我几乎得到了预期的结果。但我不太确定我是否做对了。令人惊讶的是，即使我在不​​使用 join/fork 框架的情况下执行相同的操作，我也没有注意到执行的任何时间差异。

有什么想法吗！

我正在使用jdk 7的新forkjoin框架。我有一个任务，必须使用不同的参数执行多次。

此任务扩展RecursiveTask。有100多个任务要执行，可以同时执行。这些任务是独立的，因此不需要任何同步。因此，我首先创建了所需的任务并将它们传递给 forkjoin 线程池。但是应用程序变得比在没有任何并行性的情况下运行它要慢。

我的第一个想法是，我创建了很多线程。这就是为什么我试图回收线程以减少对象创建开销，但这对性能没有影响。使用 reinitialize() 方法回收 im。此外，通过回收，性能比在没有任何并行性的情况下运行它要慢。

任务中执行的操作并非微不足道，运行线程的持续时间从 5 到 150 毫秒。该应用程序在双核机器上运行，我使用 ubuntu 和 oracle jdk 7。

我是 Scala/Akka 的新手，虽然我非常熟悉基于角色的建模的概念。我正在尝试并行化现有代码以获得更好的性能，我有两个版本：一个在 Scala/Akka 中，一个在 Java 7 的 ForkJoinPool 中。

我原以为基于actor的方法应该更快，但结果恰恰相反。Scala/Akka 大约需要 20 秒，而 Java fork/join 大约需要 17 秒。

我想知道akka本质上是否较慢？或者可能是因为我在两个实现中都使用了用普通 Java 编写的现有代码中的类？

这是今天对另一个问题的答案的“副作用” 。它更多的是关于好奇心而不是实际问题。

Java SE 7 提供了 Oracle 所称的“fork/join 框架”。这可能是一种将工作安排到多个处理器的优越方式。虽然我了解它应该如何工作，但我无法理解它的优越之处以及关于窃取工作的说法。

也许其他人更了解为什么这种方法是可取的（除了因为它有一个花哨的名字）。

fork/join 的底层原语是ForkJoinTasks，即Futures，其想法是要么立即执行工作 [原文如此]（措辞具有误导性，因为“立即”意味着它在主线程中同步发生，实际上这发生在内部a Future) 低于某个阈值或递归地将工作分成两个任务，直到达到阈值。

未来是将异步运行的任务以不透明和未指定的方式封装到对象中的概念。您有一个函数可以让您验证结果是否可用，并且您有一个函数可以让您（等待和）检索结果。
严格来说，你甚至不知道未来是否异步运行，它可以在内部执行get()。该实现在理论上也可以为每个未来生成一个线程或使用一个线程池。
在实践中，Java 将 future 作为任务队列上的任务实现，并附加一个线程池（整个 fork/join 框架也是如此）。

fork/join 文档给出了这个具体的使用示例：

这以与 Mergesort 遍历它们的方式相同的方式将任务提交到底层线程池的任务队列（感谢递归）。
例如，我们有一个包含 32 个“项目”的数组要处理，阈值为 4，然后平均拆分，它将产生 8 个任务，每个任务有 4 个“项目”，如下所示：

在单核处理器上，这将按顺序提交/执行（以非常复杂的方式）任务组 1-2-3-4-5-6-7-8。
在双核处理器上，这将提交/执行 (1,3)-(2,4)-(5,7)-(6,8) ^[1]。
在四核处理器上，这将提交/执行 (1,3,5,7)-(2,4,6,8)。

相比之下，没有所有高级魔法的幼稚实现只会立即将任务 1-2-3-4-5-6-7-8 提交到任务队列。总是。

在单核处理器上，这将提交/执行 1-2-3-4-5-6-7-8。
在双核处理器上，这将提交/执行 (1,2)-(3,4)-(5,6)-(7,8)。
在四核处理器上，这将提交/执行 (1,2,3,4)-(5,6,7,8)。

问题：

1. 不是简单地将sThreshold个连续的项目塞进一个任务中，然后一个接一个地提交到线程池的任务队列中，而是生成了一个树状的递归层次结构。这涉及为实际上什么都不做的 N 个子任务构建、引用和销毁 N+log2(N) 个对象。为什么这个优越？

2. 不保留参考位置。处理器缓存和虚拟内存都不会被这样对待。为什么这个优越？

3. 除了在单处理器系统上，任务保证不会以接近其原始顺序的顺序进行调度。如果它真的无关紧要，这可能没有问题，但它使诸如栅栏或屏障之类的东西几乎不可行。拥有类似栅栏的唯一方法是等待根对象完成，然后才提交新任务。这相当于一个完整的管道停顿（这正是您不希望发生的事情）。

4. Oracle 文档声称这种方法实现了工作窃取，因此比线程池更好。我没有看到这种情况发生。我所看到的只是将任务提交到普通线程池的一种非常复杂的方式。这应该如何神奇地实现工作窃取？

^[1]让我们不要把它弄得太复杂，并假设工作线程不会相互超越，任务都需要相同的时间来处理。否则，执行当然可能以不同的顺序发生，尽管提交是相同的。

我最近参加了一个关于并行化的好处的讲座，它可以更有效地利用多核处理器的能力来实现实时 3D 图形应用程序。本次讨论是关于 C++ 和 TBB（线程构建块）（英特尔）。我在 Java 7 中发现了 Fork/Join，但我想了解更多关于通过 OpenGL / JOGL 运行实时 3d 图形的信息。

我听说 OpenGL/JOGL 必须存在于一个线程中。我不知道这是不是真的。如果您在 Java 中具有实时图形应用程序的并行/多核编程经验，并且可以向我指出一些非常棒的资源。

有人可以提供一个简单的 JDK 7 中的 fork/join 功能示例吗？

我查看了 Oracle 提供的示例，有点混乱

我有一个主线程，我想从中生成 2 个线程来解析两个不同的 xml。我想知道在这种情况下是否应该使用 Java 7 fork-join 或者我们在 jdk 1.4 中使用的传统方式是否足以应对这种情况？

Fork Join 中实现的调度机制是否必然意味着，如果在任何时候都有可用的空闲内核，线程肯定会被调度在这些空闲内核上？

我想使用 Java fork join 来解决递归问题，但我不想为每个递归步骤显式创建一个新任务实例。原因是太多的任务等于太多的对象，在处理几分钟后就填满了我的记忆。

我在 Java 6 中有以下解决方案，但是 Java 7 有更好的实现吗？

我尝试了invoke()再次在同一任务上调用该函数（当然是在更新相关字段之后），但它似乎不起作用。