В чем причина реализации метода get метода AtomicMarkableReference в Java?

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> класс и, вероятно, не будет, даже несмотря на то, что стандартная библиотека имеет по крайней мере три класса, которые имеют private static class Pair, Добавление Pair Этот класс обсуждался разработчиками OpenJDK не раз, и предложение всегда отклонялось. Это письмо является очень хорошим объяснением, почему пара не должна быть представлена ​​в качестве стандартного класса (кроме того, весь почтовый поток очень полезен):

Проблема в том, что такие классы, как Pair, просто идут намного дальше, чтобы потворствовать желанию никогда не создавать какие-либо собственные типы. Когда мы вынуждены создавать свои собственные типы, мы начинаем более адекватно моделировать наши данные, что, как я полагаю, заставляет нас создавать хорошие абстракции и на более широких уровнях детализации.

Пока AtomicMarkableReference не выставляет его Pair класс и в Java вы не можете изменить значение переданной ссылки (таким образом, что такое изменение будет видно вызывающей стороне), единственный способ вернуть и ссылку, и битовый флаг - это вернуть одну из них из метода и установить вторую в переданную как массив аргументов. Так что речь идет не о параллелизме, не о наследии, а о решении по проектированию языка.