2

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 的上述假设和理解是否正确，如果不正确，请指出我的差距。

4

2 回答 2

1

为什么要设计 ForkJoinTask 来限制阻塞 IO 任务？

fork join 池的底层是共享的线程数量，如果这些线程上有一些 IO 工作阻塞，那么 CPU 密集型工作的线程就会减少。其他没有阻塞的工作会饿死。

如果我确实实现了阻塞 IO 任务，有什么问题？

通常，FJPool 分配的线程与处理器的数量有关。因此，如果您必须IO在线程上使用阻塞，请确保为其他任务分配足够的线程。

您还可以在不与 FJ 池共享的专用线程上隔离您的 IO 工作。但是您调用blockingIO，您的线程阻塞并被安排执行其他任务，直到解除阻塞

为什么 spring 和 play 框架都充满了使用 fork-join 执行器进行 DB 调用的示例？

play没有什么不同。他们使用专用pools于 IO 任务，因此其他任务不会受到影响。

于 2016-09-04T03:45:59.377 回答
-1

该框架不限制任何类型的处理。不建议做阻塞等。几年前我写了一篇关于这个框架的评论，这里是建议的重点。这适用于 Java7 版本，但它仍然适用于 Java8。

阻塞不是致命的，冲刺和玩阻塞，它们工作得很好。使用 Java8 时需要小心，因为有一个默认的 common-fork/join 池，并且在那里占用线程可能会对其他用户产生影响。您始终可以使用额外的开销定义自己的 f/j 池，但至少您不会干扰使用公共池的其他人。

你的情况看起来不错。您无需等待来自互联网的回复。试试看。如果您在停止线程时遇到困难，请查看 ForkJoinPool.ManagedBlocker 接口。使用该接口会通知 f/j 池您正在执行阻塞调用，并且框架将创建补偿线程。

于 2015-02-26T23:16:59.723 回答