AtomicXXX.lazySet(...) 发生在边缘之前

Question

大多数 JMM 推理中使用的 AtomicXXX.lazySet(value) 方法在边发生之前意味着什么？ javadocs 是纯粹的，Sun bug 6275329 指出：

语义是保证写入不会与任何先前的写入一起重新排序，但可能会与后续操作一起重新排序（或者等效地，可能对其他线程不可见），直到发生其他一些易失性写入或同步操作）。

但这不是关于 HB 边缘的推理，所以它让我感到困惑。这是否意味着lazySet()语义不能用HB边来表达？

更新：我会尝试具体化我的问题。我可以在以下场景中使用普通的易失性字段：

//thread 1: producer
...fill some data structure
myVolatileFlag = 1;

//thread 2: consumer
while(myVolatileFlag!=1){
   //spin-wait
}
...use data structure...

在这种情况下，在消费者中使用“数据结构”是正确的，因为易失性标志读写使HB边缘，保证生产者对“数据结构”的所有写入都将完成，并且消费者可见。但是，如果我在这种情况下使用 AtomicInteger.lazySet/get 而不是 易失性写入/读取呢？

//thread 1: producer
...fill some data structure
myAtomicFlag.lazySet(1);

//thread 2: consumer
while(myAtomicFlag.get()!=1){
   //spin-wait
}
...use data structure...

它仍然是正确的吗？我仍然可以真正了解“数据结构”值在消费者线程中的可见性吗？

这不是“空中”问题——我在这种情况下的 LMAX Disruptor 代码中看到过这种方法，但我不明白如何证明它是正确的......

Answer 1

lazySet 操作不会创建happens-before 边，因此不能保证立即可见。这是一种低级优化，只有少数用例，主要是并发数据结构。

清空链表指针的垃圾收集示例没有用户可见的副作用。首选清零，以便如果列表中的节点处于不同代，则不会强制执行更昂贵的收集来丢弃链接链。使用lazySet可以保持卫生语义，而不会产生不稳定的写入开销。

另一个例子是使用由锁保护的易失性字段，例如在 ConcurrentHashMap 中。这些字段是易失性的，以允许无锁读取，但写入必须在锁定下执行，以确保严格的一致性。由于锁保证了释放时的发生前边缘，因此优化是在写入字段时使用lazySet，并在解锁时刷新所有更新。这有助于避免不必要的停顿和总线交通，从而缩短关键部分。

如果您编写并发数据结构，那么lazySet 是一个需要注意的好技巧。它是低级优化，因此仅在性能调整时才值得考虑。

Answer 2

基于 Unsafe 的 Javadoc（AtomicInteger.lazySet 中使用 putOrderedInt）

/** 
 * Version of {@link #putObjectVolatile(Object, long, Object)}
 * that does not guarantee immediate visibility of the store to
 * other threads. This method is generally only useful if the
 * underlying field is a Java volatile (or if an array cell, one
 * that is otherwise only accessed using volatile accesses).
 */
public native void  putOrderedObject(Object o, long offset, Object x);

/** Ordered/Lazy version of {@link #putIntVolatile(Object, long, int)}  */
public native void  putOrderedInt(Object o, long offset, int x);

AtomicXXX 类中的支持字段是易失性的。 lazySet 似乎会写入这些字段，就好像它们不是易失性的一样，这会删除您期望的发生在边缘之前。正如您的链接中所述，这对于使值符合 GC 资格而无需引起易失性写入非常有用。

编辑：

这是为了回答您的更新。

如果您查看链接中提供的报价，那么您将失去易失性写入的任何内存保证。

这个lazySet不会被排序在它被写入的地方之上，但是如果没有任何其他实际的同步，你就失去了消费者将看到在它之前写入的任何更改的保证。延迟 myAtomicFlag 的写入以及在此之前的任何写入直到发生某种其他形式的同步是完全合法的。