Метод Java PriorityQueue initElementsFromCollection

Конструктор (точнее его автор) не доверяет входящей коллекции. Метод коллекции toArray может нарушить контракт и вернуть общий массив вместо создания нового. Таким образом, вызывающая сторона может получить доступ к внутренне используемому массиву созданного экземпляра PriorityQueue.

Таким образом, конструктор делает еще одну защитную копию, за исключением случаев, когда входящая коллекция является именно ArrayList, то есть даже не ее подклассом. Другими словами, он доверяет реализации ArrayListtoArray соблюдения контракта, чтобы пропустить дополнительный шаг копирования в этом конкретном случае. Вот почему даже подкласс ArrayList не будет принят, поскольку подкласс мог переопределить метод toArray.

Аналогичное недоверие было показано в реализации Stream.toList() по умолчанию, как обсуждалось в этот вопрос и разделе комментариев под этот вопрос.

Реализация по умолчанию была указана как

default List<T> toList() {
    return (List<T>) Collections.unmodifiableList(new ArrayList<>(Arrays.asList(this.toArray())));
}

потому что он не доверяет реализации toArray() сторонних реализаций Stream (в любом случае реализация JDK переопределяет метод toList()).

Штраф за эту паранойю выплачивается даже дважды. В прошлом конструктор ArrayList доверял реализации toArray() любой входящей коллекции, но сегодня это выглядит так:

public ArrayList(Collection<? extends E> c) {
    Object[] a = c.toArray();
    if ((size = a.length) != 0) {
        if (c.getClass() == ArrayList.class) {
            elementData = a;
        } else {
            elementData = Arrays.copyOf(a, size, Object[].class);
        }
    } else {
        // replace with empty array.
        elementData = EMPTY_ELEMENTDATA;
    }
}

Делая то же самое, что вы видели в конструкторе PriorityQueue, доверяйте toArray() только тогда, когда коллекция точно является ArrayList.

Поскольку в случае toList() входящая коллекция является результатом Arrays.asList(…), то есть не ArrayList, метод toArray() создаст копию, а затем конструктор ArrayList создаст другую копию. Все это, хотя исходный массив в любом случае является новым массивом, для хорошо работающих Stream реализаций…

Мы можем обобщить проблему. Идиоматическая инициализация коллекций, таких как new ArrayList<>(Arrays.asList(…)) или new ArrayList<>(List.of(…)) или аналогично для PriorityQueue, получает штраф в виде защитной копии, несмотря на то, что используются только коллекции JDK, которые должны иметь правильную toArray реализацию.

Я бы, вероятно, использовал c.getClass().getClassLoader() != null вместо c.getClass() != ArrayList.class, чтобы доверять всем встроенным коллекциям, реализация которых была загружена загрузчиком начальной загрузки. Но, возможно, этот тест окажется дороже ArrayList теста¹ или слишком много ненадежных встроенных коллекций…

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