问题标签 [forkjoinpool]

我正在使用 ForkJoinPool 创建一个私有线程池，用于处理大型的单个数据流。我不是试图使用并行性来更快地处理流，而是让多个线程在从流中读取数据记录后对它们执行相对较慢的操作。

以下是开发 Spliterator 的测试程序，它会根据并发值而不是实际工作负载进行拆分，并假设单个数据流具有线程安全的 getLine() 方法：

这可以作为一个独立的 Java 程序完美地工作，生成线程处理的值的摘要，如下所示：

但是，如果我在 JUnit 测试中运行相同的代码，我会得到如下摘要：

所以我的问题是为什么它在测试套件中运行时部分使用公共池，并且最多使用 4 个线程？看起来流对 ForkJoinPool 的亲和力以某种方式被破坏了。JUnit 测试或独立程序都没有设置任何 JVM 参数。

我们正在向数据库插入一个包含 900 万个对象（文件 + 文件夹）的目录。我们使用的是 Java8 NIO2 Files.WalkFileTree 版本的多线程版本。

问题（我们真正需要帮助的地方是）我们使用 fork –join pool 进行线程管理。最大线程数设置为 1200。 - 最初在 preVisitDirectory - 为父目录创建线程，从而增加线程数。- 一旦线程数达到 1200。不会创建新线程。- 因此本质上是在不平衡的文件树中——逻辑归结为从某个点遍历单线程文件树。- 为父目录创建的线程只是坐等子目录返回。这是一种浪费。- 因此，在最初的高速率（以及高 CPU 使用率）之后，速率会下降。

我正在开发一个库，它将一个对象DataRequest作为输入参数并基于该对象，我将构建一个 URL，然后使用 apache http 客户端调用我们的应用服务器，然后将响应返回给客户使用我们的图书馆。有些客户会调用该executeSync方法来获取相同的功能，有些客户会调用我们的executeAsync方法来获取数据。

• executeSync()- 等到我有结果，返回结果。
• executeAsync()- 立即返回一个 Future，如果需要，可以在其他事情完成后处理它。

下面是我的DataClient类，它有以上两种方法：

下面是我的DataFetcherTask类，它也有一个静态类DataRequestTask，它通过创建 URL 来调用我们的应用服务器：

每个DataRequest对象都有一个DataResponse对象。现在一旦有人通过传递DataRequest对象调用我们的库，我们在内部创建List<DataRequest>对象，然后我们DataRequest并行调用每个对象并返回列表List<DataResponse>中的每个DataResponse对象将对相应DataRequest对象产生响应的位置。

下面是流程：

• 客户将通过传递对象来调用DataClient类。DataRequest他们可以根据自己的要求调用executeSync()或方法。executeAsync()
• 现在在DataFetcherTask类（它是子类型RecursiveTask之一ForkJoinTask's）中，给定一个key对象，它是一个单一的DataRequest，我将生成List<DataRequest>然后为DataRequest列表中的每个对象并行调用每个子任务。这些子任务ForkJoinPool与父任务一样执行。
• 现在在DataRequestTask课堂上，我DataRequest通过创建一个 URL 来执行每个对象并返回它的DataResponse对象。

问题陈述：

由于这个库是在一个非常高吞吐量的环境中调用的，所以它必须非常快。对于同步调用，这里可以在单独的线程中执行吗？在这种情况下，它会产生线程的额外成本和资源以及线程上下文切换的成本，所以我有点困惑。我也在ForkJoinPool这里使用这将节省我使用额外的线程池，但它在这里是正确的选择吗？

有没有更好、更有效的方法来做同样的事情，也可以提高性能？我正在使用 Java 7 并且也可以访问 Guava 库，所以如果它可以简化任何事情，那么我也对此持开放态度。

当它在非常重的负载下运行时，我们似乎看到了一些争用。当在非常重的负载下运行时，这段代码有没有办法进入线程争用？

对于我的工作，我必须开发一个小型 Java 应用程序来解析非常大的文本文件（~6800 kb），所以我正在尝试对其进行一些优化以进行进一步的处理。使用等号 (=) 分割线作为第一个分叉任务，并使用第二个分叉任务用逗号和一些计算进行分割。这将导致单个应用程序的多个分叉任务的良好性能。

1）第一次fork和join过程：

2）第二次fork和join过程：

谁能帮帮我？

假设我有一个并行度为 n 的 ForkJoinPool 设置，并且我将这样的并行计算称为：

我这样做是为了确保在工作池中创建在那里生成的线程（我有需要隔离的系统的不同组件）。现在假设调用 this 的线程也在这个工作池中执行，我这样做：

1) 我是否阻塞了 ForkJoinPool 中的线程？如果我让 n 个线程全部阻塞在 future 上，同时尝试在工作池中安排任务，这会导致死锁吗？我不清楚 ForkJoinPool 中的“最大并行度”是否意味着（如果有 n 个非阻塞任务），将始终有 n 个线程在执行，或者是否有固定数量的线程，无论是否有被封锁。如果我改用 wait.join() 会怎样wait.join（我不需要检查异常，因为此代码中抛出的任何异常都已经生成运行时异常。如果我理解正确，join() 将允许线程在等待时执行排队的任务）

2) 如果我通过 () -> {} 创建一个可运行的“包装器”类，我是否还能从并行流的轻量级 forkjoin 任务中受益？

3）使用它是否有任何缺点/优点（假设 .join() 确实实现了我认为的工作窃取行为）：

在阅读了ForkJoinPool之后，我尝试了一个实验来测试ForkJoinPool与普通递归相比的实际速度。

我递归地计算了一个文件夹中的文件数量，令我惊讶的是，普通递归的性能比ForkJoinPool

这是我的代码。

递归任务

普通递归

目录对象

结果

• 普通递归：3ms
• ForkJoinPool：25ms

这里的错误在哪里？

我只是想了解是否存在特定阈值，低于该阈值的普通递归比 ForkJoinPool 更快。

我想使用java的fork join模型来实现双音排序。所以这里是排序器的代码

和主要（测试类）

但是每当我运行这段代码时，我都会得到

能否请您告诉我造成这种情况的原因以及如何解决。

我们开发了一个使用 Java8 并行流的 API 调用，我们获得了非常好的性能，在进行压力测试时与顺序处理相比几乎翻了一番。

我知道这取决于用例，但我将它用于加密操作，所以我认为这是一个很好的用例。

但是，我已经阅读了很多鼓励对它们非常小心的文章。还有一些文章讨论它们内部设计得不是很好，比如这里。

因此：并行流生产准备好了吗？它们是否广泛用于生产系统？

我在虚拟墙的节点上运行以下代码。该节点有 32 个 Intel Xeon E7/E5 内核和 128GB RAM。监控 CPU 使用率表明该节点远未满负荷运行。由于节点大小，此问题与大多数分叉连接问题不同。有时，该节点在多个内核上具有 20% 以上的 CPU 负载，显示出并行性的迹象，但我似乎无法让它使用更多资源。

给出一些背景；该问题是 111 个节点（Parcs/parken）的图中的最大化问题。每个公园内都隐藏着许多鸡蛋。这个数字随着每一秒的过去而呈指数下降。目标是在时间到期之前获得尽可能多的鸡蛋。'opl' 是我使用贪心算法找到的解决方案，因此为了缩小递归树的范围，我只允许在我们发现最多比贪心算法同时发现的鸡蛋少 5 个鸡蛋时进行递归。

我熟悉（多）线程，但远非专家。我以前没有使用过很多 ForkJoinPools。我也尝试将 ForkJoinPool 参数操作为 16/32，但没有成功。

当前核心负载示例

主要的：

班级：

我为仅使用 akka http 客户端（通过主机连接池）的服务配置了一个 fork join 调度程序：

服务逻辑唯一要做的就是从外部源请求，使用颚化解组，然后将颚化 ast 转换为案例类：

我想知道对于这种工作负载使用固定线程池是否更有效。该服务获得大约 150 个请求/秒，我想将 CPU 使用率保持在 1 个 CPU 之下（它目前徘徊在 1.25-1.5 个 CPU 左右）。