Java中AtomicMarkableReference的“ get”方法实现背后的原因是什么？

Question

在Java中，可以使用 AtomicMarkableReference 原子地更新对象引用以及标记位。

该javadoc的状态：

实施注意事项：此实现通过创建表示“装箱的” [reference，boolean]对的内部对象来维护可标记的引用。

根据在该类的Java 8源代码中可以看到的情况，这是正确的：

package java.util.concurrent.atomic;

public class AtomicMarkableReference<V> {

    private static class Pair<T> {
        final T reference;
        final boolean mark;
        private Pair(T reference, boolean mark) {
            this.reference = reference;
            this.mark = mark;
        }
        static <T> Pair<T> of(T reference, boolean mark) {
            return new Pair<T>(reference, mark);
        }
    }

    private volatile Pair<V> pair;

    public AtomicMarkableReference(V initialRef, boolean initialMark) {
        pair = Pair.of(initialRef, initialMark);
    }

    // [...] class methods
}

该类的get方法的设计背后是否有原因？

public V get(boolean[] markHolder) {
    Pair<V> pair = this.pair;
    markHolder[0] = pair.mark;
    return pair.reference;
}

使用这种布尔数组（而不是返回值对）有什么意义？是并发驱动的选择吗？还是遗留代码？

Answer 1

这是因为Java没有Pair<L, R>类，并且即使标准库至少具有三个具有的类的事实，Java也可能没有private static class Pair。PairOpenJDK开发人员多次讨论了添加类的问题，并且提案始终被拒绝。这封邮件很好地解释了为什么不应该将对显示为标准类（另外，整个邮件线程也非常有用）：

问题在于，像Pair这样的类只是走得更远，从而沉迷于永远不必创建我们自己的任何实际类型的欲望。当我们被迫创建自己的类型时，我们开始对数据进行更适当的建模，我相信这会导致我们在更广泛的粒度级别上创建良好的抽象。

只要AtomicMarkableReference不公开其Pair类，并且在Java中，您就无法更改传递的引用的值（以这种更改可以被调用者观察到的方式），返回引用和位标志的唯一方法是返回他们从方法，并设置第二个传入作为参数数组。因此，这与并发无关，与遗产无关，也与语言设计决策有关。