编程语言
首页 > 编程语言> > 在Java的ForkJoinTask中,fork / join的顺序是否重要?

在Java的ForkJoinTask中,fork / join的顺序是否重要?

作者:互联网

假设我们扩展了一个名为MyRecursiveTask的RecursiveTask.

然后在forkJoinTask的范围内创建两个子任务:

MyRecursiveTask t1 = new MyRecursiveTask()
MyRecursiveTask t2 = new MyRecursiveTask()
t1.fork()
t2.fork()

我认为那么“t2”将位于Workqueue的顶部(这是一个deque,它被用作worker本身的堆栈),因为我看到了fork方法的实现,如下所示:

public final ForkJoinTask<V> fork() {
    Thread t;
    if ((t = Thread.currentThread()) instanceof ForkJoinWorkerThread)
        ((ForkJoinWorkerThread)t).workQueue.push(this);
    else
        ForkJoinPool.common.externalPush(this);
    return this;
}

如果是这样,下面两个表达式的性能是否有任何差异:

表达式:

t1.join() + t2.join()

表达式2:

t2.join() + t1.join()

我认为这可能很重要.在t2.join()完成之前,t1.join()将始终阻塞(如果没有工作窃取),因为只有workQueue顶部的任务才能被激活. (换句话说,t2必须在t1加速之前加速).以下是doJoin和tryUnpush的代码.

private int doJoin() {
    int s; Thread t; ForkJoinWorkerThread wt; ForkJoinPool.WorkQueue w;
    return (s = status) < 0 ? s :
        ((t = Thread.currentThread()) instanceof ForkJoinWorkerThread) ?
        (w = (wt = (ForkJoinWorkerThread)t).workQueue).
        tryUnpush(this) && (s = doExec()) < 0 ? s :
        wt.pool.awaitJoin(w, this, 0L) :
        externalAwaitDone();
}

/**
 * Pops the given task only if it is at the current top.
 * (A shared version is available only via FJP.tryExternalUnpush)
*/
final boolean tryUnpush(ForkJoinTask<?> t) {
    ForkJoinTask<?>[] a; int s;
    if ((a = array) != null && (s = top) != base &&
        U.compareAndSwapObject
        (a, (((a.length - 1) & --s) << ASHIFT) + ABASE, t, null)) {
        U.putOrderedInt(this, QTOP, s);
        return true;
    }
    return false;
}

有没有人有这个想法?谢谢!

解决方法:

您使用Java7还是Java8很重要.在Java7中,框架为join()创建了延续线程.在Java8中,框架主要用于join(). See here. 自2010年以来,我一直在撰写关于此框架的评论.

使用RecursiveTask(来自JavaDoc)的建议:

return f2.compute() + f1.join();

这样,分裂线程继续操作本身.

由于此代码经常更改,因此不建议依赖F / J代码进行指导.例如,在Java8中使用嵌套并行流导致过多的补偿线程,代码在Java8u40中重新编写只会导致更多问题. See here.

如果你必须做多个连接,那么加入()的顺序并不重要.每个fork()使任务可用于任何线程.

标签:java,multithreading,fork-join
来源: https://codeday.me/bug/20190829/1763862.html