java - 为什么 AtomicLong 和 AtomicLongFieldUpdater 实现 CompareAndSet 的方式不同？

Question

来自AtomicLong的源代码:

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

来自AtomicLongFieldUpdater的源代码:

    public static <U> AtomicLongFieldUpdater<U> newUpdater(Class<U> tclass,
                                                           String fieldName) {
        Class<?> caller = Reflection.getCallerClass();
        if (AtomicLong.VM_SUPPORTS_LONG_CAS)
            return new CASUpdater<U>(tclass, fieldName, caller);
        else
            return new LockedUpdater<U>(tclass, fieldName, caller);
    }

    // CASUpdater extends AtomicLongFieldUpdater
        public final boolean compareAndSet(T obj, long expect, long update) {
            accessCheck(obj);
            return U.compareAndSwapLong(obj, offset, expect, update);
        }

    // LockedUpdater extends AtomicLongFieldUpdater
        public final boolean compareAndSet(T obj, long expect, long update) {
            accessCheck(obj);
            synchronized (this) {
                long v = U.getLong(obj, offset);
                if (v != expect)
                    return false;
                U.putLong(obj, offset, update);
                return true;
            }
        }

我的问题是为什么这两个类使用不同的方式来更新长值？ IE。为什么 AtomicLongFieldUpdater 有条件地回退到锁定方法，而 AtomicLong 则不然？

Answer 1

这两个类基本上具有相同的目的，它们都使用内部Unsafe类来执行“硬低级”工作。因此，质疑实现差异是合乎逻辑的。

我猜测在AtomicLongFieldUpdater中完成的回退可能只是一个遗迹。 可以通过 VM_SUPPORTS_LONG_CAS 在 AtomicLong 中定义，但仅在 AtomicLongFieldUpdater 中使用这一事实来支持这一点。

另一种可能性是 Java 作者决定在某种程度上优化性能，但他们只是在 AtomicLongFieldUpdater 中做到了。

答案可能隐藏在VM_SUPPORTS_LONG_CAS的javadoc中:

    /**
     * Records whether the underlying JVM supports lockless
     * compareAndSwap for longs. While the Unsafe.compareAndSwapLong
     * method works in either case, some constructions should be
     * handled at Java level to avoid locking user-visible locks.
     */
    static final boolean VM_SUPPORTS_LONG_CAS = VMSupportsCS8();

恐怕我们必须直接询问作者才能了解确切的推理和含义。看起来 Java 5 中已经存在几乎相同的代码 - 请参阅 source code来自 2007 年 OpenJDK 的“初始加载”提交。我认为在此之前很难进行提交...