ForkJoinPool 和 Future.Get

ForkJoinPool and Future.Get

假设我有一个并行度为 n 的 ForkJoinPool 设置,并且我这样调用并行计算:

 workpool.submit(
            () -> {
                    objects.values().parallelStream().forEach(obj -> {
                        obj.foo();
                    });
                });

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

 Future<?> wait =  workpool.submit(
            () -> {
                    objects.values().parallelStream().forEach(obj -> {
                        obj.foo();
                    });
                });
 wait.get()

1) 我是否阻塞了 ForkJoinPool 中的线程?如果我让 n 个线程都阻塞在 futures 上,同时尝试在工作池中安排任务,这会导致死锁吗?不清楚ForkJoinPool中的"maximum degree of parallellism"是指(如果有n个非阻塞任务)总是有n个线程在执行,还是有固定数量的线程,不管有没有被封锁。如果我使用 wait.join() 而不是 wait.join 怎么办(我不需要检查异常,因为此代码中抛出的任何异常都会产生运行时异常。如果我理解正确, join() 将允许线程等待时执行排队的任务)

2) 如果我通过 () -> {}

3) 是否有任何 downside/upside 可以改用它(假设 .join() 确实实现了我认为的工作窃取行为):

        CompletableFuture.supplyAsync(this::mylambdafunction, workpool)  
             .thenAccept(this::mynextfunction);

对第 1 点的回应: 在没有看到实际方法实现的情况下,很难知道您的代码是否会阻塞。处理阻塞代码的一种方法是增加 forkjoin 线程池中的线程数。通常,对于计算密集型任务,forkjoin 线程中的线程数为 n+1,其中 n = 处理器数。或者,如果您有 I/O 阻塞,您可以使用 ManagedBlocker。

对第 2 点的回复:

对第 3 点的回应: completableFuture 代码的明显优势是 thenAccept 是非阻塞的。因此,控制将立即通过您的 CompletableFuture 块进入下一条语句而无需等待,而在您使用 ForkJoin 池编写的早期代码中, wait.get() 将阻塞直到您获得答案并且直到那时才会继续。