在 CyclicBarrier 或 CountDownLatch 上缓存刷新，就像使用同步关键字时一样答案

【问题标题】：Cache flush on CyclicBarrier or CountDownLatch like when using synchronized keyword在 CyclicBarrier 或 CountDownLatch 上缓存刷新，就像使用同步关键字时一样
【发布时间】：2011-11-21 12:43:42
【问题描述】：

有什么方法可以确保 java 在 CyclicBarrier 或 CountDownLatch 允许我们在不使用 synchronized 关键字的情况下继续（就像 synchronized 关键字一样）之前刷新已经完成的写入缓存？

【问题讨论】：

标签： java multithreading cpu-cache

【解决方案1】：

我认为API已经保证了。

http://download.oracle.com/javase/6/docs/api/java/util/concurrent/CyclicBarrier.html

内存一致性效果：调用 await() 之前线程中的动作 happen-before 动作是屏障动作的一部分，而后者又是 happen-before 动作在其他线程中从相应的 await() 成功返回之后。

http://download.oracle.com/javase/6/docs/api/java/util/concurrent/package-summary.html#MemoryVisibility

只有当写操作发生在读操作之前发生时，才能保证一个线程的写结果对另一个线程的读操作可见。 ... 调用 CyclicBarrier.await 之前的操作 happen-before 由屏障操作执行的操作，以及由屏障操作执行的操作 happen-before 成功返回之后的操作来自其他线程中的相应等待。

这意味着

thread 1                  thread 2

write x1;                 write x2
barrier.await();          barrier.await();
read x2                   read x1

不需要额外的同步； read x2 会看到write x2 的结果

【讨论】：

是的，这保证了操作顺序，但我没有看到任何文本提到将缓存值刷新到内存中（这样等待线程肯定会看到彼此的结果）——我的意思是，如果 volatile需要关键字来确保写入的值将在刚刚通过屏障的所有等待线程之间共享
happen-before 在这里是一个技术术语；如果write x2 happen-before read x2，读会看到写的效果。您可以将其视为“缓存刷新”；尽管 java 内存模型不再使用缓存/刷新概念。