Java - 连续并行流之间的缓存一致性？

Question

考虑以下代码(乍一看并不完全是这样)。

static class NumberContainer {

    int value = 0;

    void increment() {
        value++;
    }

    int getValue() {
        return value;
    }
}

public static void main(String[] args) {

    List<NumberContainer> list = new ArrayList<>();
    int numElements = 100000;
    for (int i = 0; i < numElements; i++) {
        list.add(new NumberContainer());
    }

    int numIterations = 10000;
    for (int j = 0; j < numIterations; j++) {
        list.parallelStream().forEach(NumberContainer::increment);
    }

    list.forEach(container -> {
        if (container.getValue() != numIterations) {
            System.out.println("Problem!!!");
        }
    });
}

我的问题是:为了绝对确定“问题!!!”不会打印，NumberContainer类中的“value”变量是否需要标记为volatile？

让我解释一下我目前是如何理解这一点的。

• 在第一个并行流中，NumberContainer-123(比方说)按 ForkJoinWorker-1(比方说)递增。因此 ForkJoinWorker-1 将拥有 NumberContainer-123.value 的最新缓存，即 1。(但是，其他 fork-join worker 将拥有 NumberContainer-123.value 的过时缓存 - 他们将存储值 0。在某些时候，这些其他工作人员的缓存将被更新，但这不会立即发生。)

• 第一个并行流完成，但公共(public) fork-join 池工作线程未被终止。然后第二个并行流开始，使用非常相同的公共(public) fork-join 池工作线程。

• 现在假设，在第二个并行流中，递增 NumberContainer-123 的任务分配给 ForkJoinWorker-2(比方说)。 ForkJoinWorker-2 将拥有自己的缓存值 NumberContainer-123.value。如果在 NumberContainer-123 的第一次和第二次增量之间经过了很长一段时间，那么 ForkJoinWorker-2 的 NumberContainer-123.value 缓存可能是最新的，即值 1 将被存储，并且一切都是好的。但是，如果 NumberContainer-123 非常短，第一次和第二次增量之间耗时会怎样？那么可能 ForkJoinWorker-2 的 NumberContainer-123.value 缓存已经过时，存储了值 0，导致代码失败!

我上面的描述是否正确？如果是这样，谁能告诉我两次递增操作之间需要什么样的时间延迟才能保证线程之间的缓存一致性？或者，如果我的理解有误，那么有人可以告诉我是什么机制导致线程局部缓存在第一个并行流和第二个并行流之间被“刷新”吗？

Answer 1

它应该不需要任何延迟。当您离开 ParallelStream 的 forEach 时，所有任务都已完成。这在 forEach 的增量和结束之间建立了一个happens-before 关系。所有 forEach 调用都按从同一线程调用的顺序进行排序，同样地，检查发生在所有 forEach 调用之后。

int numIterations = 10000;
for (int j = 0; j < numIterations; j++) {
    list.parallelStream().forEach(NumberContainer::increment);
    // here, everything is "flushed", i.e. the ForkJoinTask is finished
}

回到你关于线程的问题，这里的诀窍是，线程是无关紧要的。内存模型取决于happens-before 关系，而 fork-join 任务确保 happens-before 调用 forEach 和操作体，以及操作体和 forEach 的返回值之间(即使返回值是 Void)

另见 Memory visibility in Fork-join

正如@erickson 在评论中提到的，

If you can't establish correctness through happens-before relationships, no amount of time is "enough." It's not a wall-clock timing issue; you need to apply the Java memory model correctly.

此外，从“刷新”内存的角度来考虑它是错误的，因为还有更多的事情会影响你。例如，冲洗是微不足道的:我没有检查过，但可以打赌任务完成时只有内存障碍；但是你可能会得到错误的数据，因为编译器决定优化非 volatile 读取(变量不是 volatile 的，并且在这个线程中没有改变，所以它不会改变，所以我们可以将它分配给一个寄存器，et voila)，以 happens-before 关系允许的任何方式重新排序代码，等等。

最重要的是，所有这些优化都可以并且会随着时间的推移而改变，所以即使您转到生成的程序集(可能会因加载模式而异)并检查所有内存屏障，也不能保证您的代码会工作除非你能证明你的读取发生在你的写入之后，在这种情况下，Java 内存模型就在你这一边(假设 JVM 中没有错误)。

至于巨大的痛苦，ForkJoinTask 的目标就是让同步变得微不足道，所以尽情享受吧。它(似乎)是通过将 java.util.concurrent.ForkJoinTask#status 标记为易变的来完成的，但这是您不应该关心或依赖的实现细节。