如果weakCompareAndSet的实现方式与compareAndSet完全相同,那么它如何虚假地失败？

Question

(请注意,这个问题不是关于CAS,而是关于"可能是虚假失败的" Javadoc).

从上述两种方法之间的Javadoc唯一不同的AtomicInteger类就是weakCompareAndSet包含批注:"可能意外失败".

现在,除非我的眼睛受到某些咒语的欺骗,否则这两种方法看起来都是完全一样的:

public final boolean compareAndSet(int expect, int update) {
  return unsafe.compareAndSwapInt(this, valueOffset, expect, update);
}

/* ...
 * May fail spuriously.
 */
public final boolean weakCompareAndSet(int expect, int update) {
  return unsafe.compareAndSwapInt(this, valueOffset, expect, update);
}

所以我意识到"May"并不意味着"必须",但为什么我们都不开始将它添加到我们的代码库中:

public void doIt() {
    a();
}

/**
 * May fail spuriously
 */
public void weakDoIt() {
    a();
}

我真的很困惑那个看起来与compareAndSet()相同的weakCompareAndSet(),但是"可能会失败",而另一个则不能.

显然,"弱"和"伪故障"是相关的方式来"之前发生"的排序,但我还是通过这两个的AtomicInteger(和AtomicLong的等)方法很困惑:因为很明显他们称完全一样不安全.compareAndSwapInt方法.

我之所以特别迷茫AtomicIntegerJava 1.5中得到了介绍,所以Java内存模型变化后(所以它显然不是东西,可以"在1.4意外失败",但其行为改为"不得以1.5意外失败").

Answer 1

实施和规范之间存在差异......

虽然在特定实现方式上提供不同的实现可能没有多大意义,但是可能在不同硬件上的未来实现可能想要.这种方法在API中的重要性是值得商榷的.

在定义排序之前,weak方法也没有发生.非weak版本的行为类似于volatile字段.