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!!!");
        }
    });
}

我的问题是：为了绝对确定 "Problem!!!" 不会被打印，NumberContainer class 中的 "value" 变量是否需要被标记为不稳定？

让我解释一下我目前的理解。

在第一个并行流中，NumberContainer-123（比方说）增加了 ForkJoinWorker-1（比方说）。因此 ForkJoinWorker-1 将拥有 NumberContainer-123.value 的最新缓存，即 1。（但是，其他 fork-join worker 将拥有 NumberContainer-[=39= 的过时缓存] - 他们将存储值 0。在某些时候，这些其他工作人员的缓存将被更新，但这不会立即发生。）
第一个并行流完成，但未终止常见的 fork-join 池工作线程。然后第二个并行流开始，使用非常相同的公共 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值，导致代码失败！

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

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 的 return 之间（即使 returned 值为 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.

另外，用"flushing"记忆来想是不对的，影响你的事情还有很多。例如，冲洗是微不足道的：我没有检查过，但可以打赌任务完成时只有内存障碍；但是你可能会得到错误的数据，因为编译器决定优化非易失性读取（变量不是易失性的，并且在这个线程中没有改变，所以它不会改变，所以我们可以将它分配给一个寄存器，et voila), 以 happens-before 关系允许的任何方式重新排序代码，等等

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

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

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

Java - cache coherence between successive parallel streams?

caching

volatile