问题标签 [forkjoinpool]

ForkJoinTask明确指出“ 可细分任务也不应该执行阻塞 I/O ”。它的主要目标是“计算纯函数或对纯孤立对象进行操作的计算任务”。我的问题是：-

1. 为什么要设计 ForkJoinTask 来限制阻塞 IO 任务？
2. 如果我确实实现了阻塞 IO 任务，有什么问题？
3. 为什么 spring 和play框架都充满了使用 fork-join 执行器进行 DB 调用的示例？

在我的场景中，单个请求执行两种类型的工作，其中一种是加密，它将 CPU 核心推到 100% 持续 200 毫秒，其次是很少的数据库调用。任何类型的静态分区，例如用于加密的 6 个线程和用于阻塞 IO 的 2 个线程，都不会提供 CPU 的最佳使用率。因此，拥有一个 fork-join 执行器，在线程数量上超过总 CPU 计数的一定程度的过度配置，再加上工作窃取，将确保更好地使用 CPU 资源。

我对 forkjoin executor 的上述假设和理解是否正确，如果不正确，请指出我的差距。

我设置了一个 ForkJoinPool 来使用我一半的 CPU，如下所示：

但是，当我提交诸如那里描述的合并排序之类的作业时，该池正在使用我机器 CPU 的 80+%。

这是预期的吗？如果是这样，有没有办法有效地限制工作线程的数量？

在为 ForkJoinPool 执行了一个非常好的示例之后，该示例与在目录及其子目录中搜索具有特定扩展名的文件有关，我想到了一个难题。该程序在找到带有该目录的子目录时分叉成多个任务，换句话说，每个子目录搜索都成为一个单独的任务，并且由于在双核处理器环境中进行并行处理，因此处理速度比正常情况要快。该示例可以在 http://howtodoinjava.com/2014/05/27/forkjoin-framework-tutorial-forkjoinpool-example/找到

我的问题是这种处理是否可以用于像斐波那契数列这样的顺序处理任务，其中每个结果都没有。在系列中是前两个计算的结果。这种计算能否以某种方式分叉成多个任务，从而更快地计算结果？

我正在尝试实现一个 Fork Join Pool，它将带一个节点的子节点并同时探索它们。但是我认为我的 fork 连接池执行线程然后关闭太快，导致线程停止执行？

到目前为止，我有这个代码：

主要方法：

这是我运行的课程：

我已经删除了 compute() 中的大部分代码，因为我认为它与问题无关。

我认为问题在于 forkJoinPool.shutdown() 行在已创建的线程完成执行之前被执行。有什么方法可以确保线程在我循环回到 while 循环的顶部之前完成？

当队列已满时，我需要阻止 ForkJoinPool 上的线程。这可以在标准的 ThreadPoolExecutor 中完成，例如：

我知道，ForkJoinPool 中有一些 Dequeue，但我无法通过它的 API 访问它。

更新：请看下面的答案。

这是java.util.concurrent.CountedCompleter类的代码片段（JDK 1.8.0_25）。

这让我真的很困惑。文档说：“然后类似地尝试完成这个任务的完成者”，但我没有看到在这个任务的完成者上调用任何“完成”；或任何其他调用它。

有人在这门课上工作过吗？这是文档或实施的问题吗？我也可能用错误的方式烹饪它。任何如何正确处理此类的想法都值得赞赏。

我想Runnable通过一种方法将任务提交到 ForkJoinPool：

注意，我使用 JDK 7。

在后台，它们被转换为 ForkJoinTask 对象。我知道 ForkJoinPool 在将任务递归地拆分为较小的任务时是有效的。

问题：

如果没有递归，工作窃取在 ForkJoinPool 中是否仍然有效？

在这种情况下值得吗？

更新 1： 任务很小并且可能不平衡。即使对于严格相等的任务，诸如上下文切换、线程调度、停放、页面未命中等之类的事情也会阻碍导致不平衡。

更新 2： Doug Lea 在并发 JSR-166 兴趣组中写道，给出了一个提示：

当所有任务都是异步的并提交到池而不是分叉时，这也大大提高了吞吐量，这成为构建参与者框架以及许多您可能使用 ThreadPoolExecutor 的普通服务的合理方式。

我认为，当涉及到相当小的 CPU 密集型任务时，ForkJoinPool 是要走的路，这要归功于这种优化。要点是这些任务已经很小，不需要递归分解。工作窃取工作，无论是大任务还是小任务 - 任务都可以被另一个空闲的工作人员从忙碌的工作人员的双端队列中抢走。

更新 3： ForkJoinPool 的可扩展性- Akka 乒乓球团队的基准测试显示了很好的结果。

尽管如此，要更有效地应用 ForkJoinPool 需要进行性能调整。

这个小代码片段永远不会在 jdk8u45 上完成，并且曾经在 jdk8u20 上正确完成：

Phaser的文档指出

在 ForkJoinPool 中执行的任务也可以使用 Phasers，这将确保在其他人被阻塞等待阶段推进时执行任务有足够的并行性。

但是ForkjoinPool#mangedBlock 的 javadoc指出：

如果在 ForkJoinPool 中运行，可能会首先扩展池以确保足够的并行度

那里只有一个可能。所以我不确定这是否是一个错误，或者只是不依赖 Phaser/ForkJoinPool 合约的错误代码：Phaser/ForkJoinPool 组合的合约有多难防止死锁？

我的配置：

1. Linux adc 3.14.27-100.fc19.x86_64 #1 SMP 2014 年 12 月 17 日星期三 19:36:34 UTC x86_64 x86_64 x86_64 GNU/Linux
2. 8核i7

我们在 java 中有三种不同的多线程技术 - Fork/Join pool, Executor Service & CountDownLatch

分叉/加入池（http://www.javacodegeeks.com/2011/02/java-forkjoin-parallel-programming.html）

Fork/Join 框架旨在使分治算法易于并行化。这种类型的算法非常适合可以分为两个或多个相同类型的子问题的问题。他们使用递归将问题分解为简单的任务，直到这些任务变得简单到可以直接解决。然后将子问题的解决方案组合起来以给出原始问题的解决方案

ExecutorService是一个扩展 Executor 类的接口，代表异步执行。它为我们提供了管理异步任务结束和检测进度的机制。

invokeAll()：执行给定的任务，返回一个 Futures 列表，在所有完成时保存它们的状态和结果。Future.isDone() 对于返回列表的每个元素都是 true。

CountDownLatch：（http://examples.javacodegeeks.com/core-java/util/concurrent/countdownlatch-concurrent/java-util-concurrent-countdownlatch-example/）

CountDownLatch 用于同步以允许一个或多个线程等待，直到在其他线程中执行的一组操作完成。

我的假设：

在这两种选择中，只有在完成所有任务/线程后才能知道最终结果。

这三种选择是互补的还是互补的？

我正在多线程环境中经历不同的并发模型（http://tutorials.jenkov.com/java-concurrency/concurrency-models.html）

本文重点介绍了三种并发模型。

1. 并行工作者

   第一个并发模型就是我所说的并行工作者模型。新来的工作分配给不同的工人。

2. 流水线

   工人像工厂流水线上的工人一样被组织起来。每个工人只完成全部工作的一部分。当该部分完成后，工人将工作转发给下一个工人。

   每个工作人员都在自己的线程中运行，并且不与其他工作人员共享任何状态。这有时也称为无共享并发模型。

3. 功能并行

   函数并行的基本思想是你使用函数调用来实现你的程序。函数可以被视为相互发送消息的“代理”或“参与者”，就像在流水线并发模型（AKA 反应式或事件驱动系统）中一样。当一个函数调用另一个函数时，这类似于发送消息。

现在我想为这三个概念映射 java API 支持

1. Parallel Workers：是ExecutorService、ThreadPoolExecutor、CountDownLatch API 吗？

2. 装配线：将​​事件发送到JMS等消息传递系统并使用队列和主题的消息传递概念。

3. 功能并行：在某种程度上ForkJoinPool和 java 8 流。与流相比，ForkJoin 池更容易理解。

我映射这些并发模型是否正确？如果不是请纠正我。