Коллекции emptyList / singleton / singletonList / List / Set toArray

Он очистит только элемент в индексе сразу после, последний элемент в исходном списке, поэтому в первом примере список пуст, следовательно, он обнуляет элемент с нулевым индексом (первый элемент, который является "1").

В вашем последнем примере так получилось, что последний элемент находится сразу после последнего элемента в исходном списке. Зная, что последний сценарий на самом деле не поможет в определении размера списка, потому что сделал допускает нулевые значения.

Но если список не допускает null (например, неизменяемые списки, представленные в Java 9), то это полезно, потому что в случае, если вы перебираете возвращаемый массив, вы не хотели бы обрабатывать лишние элементы, и в этом случае вы можете остановить итератор на первом нулевом элементе.

Из исходного кода JDK 9 для ArrayList:

@SuppressWarnings("unchecked")
public <T> T[] toArray(T[] a) {
    if (a.length < size)
        // Make a new array of a's runtime type, but my contents:
        return (T[]) Arrays.copyOf(elementData, size, a.getClass());
    System.arraycopy(elementData, 0, a, 0, size);
    if (a.length > size)
        a[size] = null;
    return a;
}

а в Arrays.ArrayList реализация List, возвращенная Arrays.asList:

@Override
@SuppressWarnings("unchecked")
public <T> T[] toArray(T[] a) {
    int size = size();
    if (a.length < size)
        return Arrays.copyOf(this.a, size,
                             (Class<? extends T[]>) a.getClass());
    System.arraycopy(this.a, 0, a, 0, size);
    if (a.length > size)
        a[size] = null;
    return a;
}

Если размер списка, который нужно преобразовать в массив, равен size, то они оба устанавливают a[size] в null.

В пустом списке size - это 0, поэтому для a[0] установлено значение null, а другие элементы не затрагиваются.

В одноэлементном списке size - это 1, поэтому для a[1] устанавливается значение null, а другие элементы не затрагиваются.

Если размер списка на единицу меньше длины массива, a[size] относится к последнему элементу массива, поэтому он устанавливается на null. В вашем примере у вас есть null во второй позиции (индекс 1), поэтому он установлен на null в качестве элемента. Если бы кто-то искал null для подсчета элементов, они бы остановились здесь, а не на другом null, которым является null, полученный в результате установки следующего элемента вне содержимого списка на null. Эти null нельзя отличить друг от друга.

Код toArray (T [] a) из (например) ArrayList довольно ясен:

public <T> T[] toArray(T[] a) {
    if (a.length < size)
        // Make a new array of a's runtime type, but my contents:
        return (T[]) Arrays.copyOf(elementData, size, a.getClass());
    System.arraycopy(elementData, 0, a, 0, size);
    if (a.length > size)
        a[size] = null;
    return a;
}

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

Метод <T> T[] toArray(T[] a) в Collection странный, потому что он пытается выполнить две цели одновременно.

Сначала посмотрим на toArray(). Это берет элементы из коллекции и возвращает их в Object[]. То есть типом компонента возвращаемого массива всегда является Object. Это полезно, но не подходит для пары других вариантов использования:

1) Вызывающий хочет повторно использовать существующего массива, если это возможно; и

2) Вызывающий хочет указать тип компонента возвращаемого массива.

Обработка случая (1) оказывается довольно тонкой проблемой API. Вызывающий хочет повторно использовать массив, поэтому его явно необходимо передать. В отличие от метода toArray() без аргументов, который возвращает массив нужного размера, если массив вызывающего абонента используется повторно, нам нужно чтобы вернуть количество скопированных элементов. Хорошо, давайте получим API, которое выглядит так:

int toArray(T[] a)

Вызывающий передает массив, который используется повторно, а возвращаемое значение - это количество элементов, скопированных в него. Массив не нужно возвращать, потому что у вызывающего уже есть ссылка на него. Но что, если массив слишком мал? Ну, может, выбросить исключение. Фактически, это то, что делает Vector.copyInto.

void copyInto​(Object[] anArray)

Это ужасный API. Он не только не возвращает количество скопированных элементов, но и выдает IndexOutOfBoundsException, если целевой массив слишком короткий. Поскольку Vector является параллельной коллекцией, размер может измениться в любое время до вызова, поэтому вызывающий не можешь гарантирует, что целевой массив имеет достаточный размер, и не может знать количество скопированных элементов. Единственное, что может сделать вызывающий, - это заблокировать вектор вокруг всей последовательности:

synchronized (vec) {
    Object[] a = new Object[vec.size()];
    vec.copyInto(a);
}

Фу!

API Collections.toArray(T[]) позволяет избежать этой проблемы за счет другого поведения, если целевой массив слишком мал. Вместо того, чтобы генерировать исключение, подобное Vector.copyInto (), он выделяет массив новый нужного размера. Это позволяет отказаться от повторного использования массива в пользу более надежной работы. Теперь проблема в том, что вызывающий не может определить, был ли его массив повторно использован или был выделен новый. Таким образом, возвращаемое значение toArray(T[]) должно возвращать массив: массив аргументов, если он был достаточно большим, или вновь выделенный массив.

Но теперь у нас есть другая проблема. У нас больше нет способа сообщить вызывающей стороне количество элементов, скопированных из коллекции в массив. Если целевой массив был недавно выделен или массив оказался точно подходящего размера, то длина массива равна количеству скопированных элементов. Если целевой массив больше, чем количество скопированных элементов, метод пытается сообщить вызывающей стороне количество скопированных элементов, записывая null в расположение массива один за пределами, последний элемент, скопированный из коллекции. Если известно, что исходная коллекция не имеет нулевых значений, это позволяет вызывающей стороне определить количество скопированных элементов. После вызова вызывающий может искать первое нулевое значение в массиве. Если он есть, его положение определяет количество копируемых элементов. Если в массиве нет нуля, он знает, что количество скопированных элементов равно длине массива.

Откровенно говоря, это довольно неубедительно. Однако, учитывая ограничения языка в то время, я признаю, что у меня нет лучшей альтернативы.

Я не думаю, что когда-либо видел код, который повторно использует массивы или таким образом проверяет наличие нулей. Вероятно, это пережиток первых дней, когда выделение памяти и сборка мусора были дорогостоящими, поэтому люди хотели повторно использовать память в максимально возможной степени. Совсем недавно принятой идиомой для использования этого метода был второй вариант использования, описанный выше, то есть, чтобы установить желаемый тип компонента массива следующим образом:

MyType[] a = coll.toArray(new MyType[0]);

(Кажется расточительным выделять для этой цели массив нулевой длины, но оказывается, что это распределение может быть оптимизировано JIT-компилятором, а очевидная альтернатива toArray(new MyType[coll.size()]) на самом деле работает медленнее. Это связано с необходимостью инициализировать массив в нули, а затем заполнить его содержимым коллекции (см. статью Алексея Шипилева на эту тему, Массивы мудрости древних.)

Однако многим кажется, что массив нулевой длины противоречит здравому смыслу. В JDK 11 есть новый API, который позволяет вместо этого использовать ссылку на конструктор массива:

MyType[] a = coll.toArray(MyType[]::new);

Это позволяет вызывающей стороне указать тип компонента массива, но позволяет коллекции предоставлять информацию о размере.