问题标签 [forkjoinpool]

例如，有一个LinkedList <ForkJoinTask>。ForkJoinTasks然后我期待结果：

第一种方式：

第二种方式：

在第二种情况下，命令task.get()导致命令doJoin()并且不抛出异常。

我如何打断这些期望：task.join 或 task.get。

如果我运行以下代码：

我得到（例如）以下输出：

在我看来，普通的 ForkJoinPool 使用 4 个线程，然后它们被阻塞一秒钟，然后运行最后两个作业。

但据我了解，常见的 ForkJoinPool 默认使用 Runtime.getRuntime().availableProcessors() - 1 个线程，在我的情况下是 3 个，所以我希望在 ~82ms 而不是 4 个时打印三个作业。

是我的代码或理解有问题吗？

ETA：在 forEach 中打印出 Thread.currentThread().getId() 还显示了 4 个不同的线程 ID。

我想用ManagedBlockerwithCompletableFuture来防止ForkJoinPool.commonPool疲惫，即：

我应该注意使用ManagedBlockerwith的任何注意事项吗？CompletableFuture

我有一个 Shipment 对象的列表，我需要调用 API 来获取有关每个 Shipment 的一些信息。我正在尝试并行进行这些网络调用。所以我正在使用 Java 8parallelStream()并将其提交给ForkJoinPool如下自定义：

我有两个问题：

1. 我想优化我的线程数ForkJoinPool，所以我需要检查它的执行情况。如果请求没有被池立即处理和处理，我是否可以记录？
2. 我的系统流量很大。因此，如果我执行 a submit()and get()on an autowired ForkJoinPool，我的代码会等待来自不同请求的 Shipments 吗？我的意思是，假设我同时收到 2 个请求。Request1 有 3 个 Shipments 与之关联，Request2 有 5 个 Shipments。那么上面的代码会等到所有 8 次发货完成吗？

谢谢。

我从互联网上下载了一些现有的代码。我只做了一些修改就运行了它。在一种情况下，我没有得到我想要的东西。这是代码 -

检查以下摘录 -

我添加了 1 秒的睡眠时间，然后打印了另一条语句。但是，如果我运行代码，我看不到该语句被打印出来。我不明白为什么。为什么不会打印出来？实际上执行的结果是——

我也期待下面一行 - “Done it ya”..

这是 ForkJoinPool 默认构造函数。

这都是参数构造函数。

MAX_CAP 是

为什么限制 MAX_CAP 和 0x7fff 有特殊意义？

为什么静态变量容易受到攻击，而在 java 中使用 fork join 时其他变量却没有。假设一个类 A 有两个变量

现在在递归动作类 B

// 我得到的输出

我有一个如下的Java代码：

现在这段代码运行得足够快，使用了我机器上的所有 32 个线程，每个线程的利用率都在 70-80% 左右。

奇怪的是，每隔几分钟左右，所有线程的 CPU 利用率都会下降到 0%，除了 2 个线程（有时是 1 个）会上升到 100%。大约一分钟后，它们会再次以 70-80% 的速度嗡嗡作响。这种行为每隔几分钟左右就会重复一次。

我无法确定可能导致这种情况的原因。任何想法都会有所帮助。

我正在使用 CompletableFuture 异步执行从列表源生成的流。

所以我正在测试重载方法，即 CompletableFuture 的“supplyAsync”，其中一种方法仅采用单个供应商参数，而另一种采用供应商参数和执行器参数。这是两者的文档：

一

supplyAsync（供应商供应商）

返回一个新的 CompletableFuture，它由在 ForkJoinPool.commonPool() 中运行的任务异步完成，其值通过调用给定的供应商获得。

第二

supplyAsync(Supplier 供应商，Executor 执行者)

返回一个新的 CompletableFuture，它由在给定执行程序中运行的任务异步完成，其值通过调用给定供应商获得。

这是我的测试课：

“useCompletableFuture”方法大约需要 4 秒才能完成，而“useCompletableFutureWithExecutor”方法只需 1 秒即可完成。

不，我的问题是，可以做开销的 ForkJoinPool.commonPool() 有什么不同的处理？那我们不应该总是更喜欢自定义执行器池而不是 ForkJoinPool 吗？

从这个链接，我只是部分理解，至少在某些时候，java嵌套并行流存在问题。但是，我无法推断出以下问题的答案：

假设我有一个外部 srtream 和一个内部流，它们都使用并行流。事实证明，根据我的计算，如果内部流首先完全并行完成，然后（如果且仅cpu核心可用）做外部流。我认为这对于大多数人的情况都是正确的。所以我的问题是：

Java会先并行执行内部流，然后再处理外部流吗？如果是这样，它是在编译时还是在运行时做出决定？如果在运行时，JIT 是否足够聪明地意识到如果内部流确实有超过足够的元素（例如数百个）而不是核心数（32），那么它肯定应该使用所有 32 个核心来处理在从外部流移动到下一个元素之前的内部流；但是，如果元素的数量很小（例如 < 32），那么“也并行处理”来自“下一个”外部流元素的元素是可以的。