Краткий ответ

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

Исторический контекст

ArrayList построен поверх динамического массива. Такой подход решает проблему хранения последовательности элементов, размер которой заранее неизвестен: доступ по индексу остаётся быстрым, а внутренний массив при необходимости заменяется на более вместительный.

Динамический массив обычно сохраняет некоторый запас ёмкости. Этот запас нужен, чтобы каждое добавление не требовало немедленного выделения новой памяти и копирования всех элементов. trimToSize появился как средство добровольно вернуть неиспользуемую часть этого запаса, когда дальнейший рост списка маловероятен.

Постановка проблемы

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

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

Подробное решение

ArrayList хранит отдельно размер — число логических элементов — и ёмкость — длину внутреннего массива. Удаление сдвигает оставшиеся элементы, уменьшает размер и освобождает ссылки в освободившихся ячейках, но не обязательно уменьшает сам массив.

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

При следующем добавлении, когда свободного места нет, ArrayList снова расширяет массив. Расширение также требует копирования элементов, поэтому последовательность «удалить — сжать — добавить» может многократно копировать почти весь список.

Обычная стратегия — позволить списку сохранять запас ёмкости во время активных изменений и вызвать trimToSize один раз после окончания формирования коллекции. Компромисс заключается в выборе между экономией памяти и стоимостью будущих операций роста: уменьшение ёмкости оправдано, если список долго останется примерно такого же размера.

Важно не путать ёмкость с количеством элементов. Уменьшение внутреннего массива не меняет логическое содержимое списка, но может повлиять на производительность последующих добавлений. Кроме того, конкретные детали роста массива являются особенностями реализации, поэтому нельзя полагаться на точный коэффициент расширения как на контракт API.

Минимальный пример показывает нежелательный и предпочтительный варианты:

import java.util.ArrayList;

ArrayList<Integer> values = new ArrayList<>();
for (int i = 0; i < 100_000; i++) {
    values.add(i);
}

for (int i = 0; i < 50_000; i++) {
    values.remove(values.size() - 1);
    // values.trimToSize(); // лишнее сжатие внутри цикла
}

values.trimToSize(); // разумно после завершения изменений

В этом примере удаление с конца не требует сдвига элементов и обычно выполняется быстро, но промежуточное сжатие после каждого удаления всё равно создало бы повторные перевыделения массива.

Ситуация из практики

Сервис формирует список результатов пакетной обработки. Сначала в нём находятся десятки тысяч элементов, затем часть результатов удаляется, после чего список ещё несколько раз пополняется. Разработчик добавляет trimToSize после каждого удаления, чтобы снизить потребление памяти.

Рассматривались три варианта. Постоянное сжатие уменьшает запас памяти, но вызывает лишние копирования. Полный отказ от сжатия минимизирует стоимость изменений, однако может оставить заметную избыточную ёмкость. Сжатие после завершения всей пакетной обработки сохраняет эффективность промежуточных операций и освобождает неиспользуемую память в стабильном состоянии.

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

Что кандидаты часто упускают

Вопрос: Уменьшает ли удаление элементов из ArrayList ёмкость его внутреннего массива автоматически?

Ответ: Обычно нет. Удаление уменьшает размер списка и освобождает ссылки на удалённые элементы, но сохранение текущей ёмкости позволяет эффективно добавлять новые элементы. Для явного уменьшения ёмкости существует trimToSize, однако его вызов имеет стоимость копирования.
Вопрос: Почему стоимость одного trimToSize нельзя считать постоянной, даже если сам вызов выглядит простым?

Ответ: При уменьшении ёмкости нужно создать новый массив и перенести в него все текущие элементы. Поэтому стоимость зависит от размера списка и составляет порядка O(n). Кроме времени копирования, возникают выделение нового объекта массива и последующая работа сборщика мусора с прежним массивом.
Вопрос: Всегда ли сохранение избыточной ёмкости ArrayList является проблемой?

Ответ: Нет. Это может быть сознательным компромиссом в пользу скорости будущих добавлений. Проблема возникает, когда список надолго уменьшился, занимает много памяти и больше не будет расти; в таком случае однократный trimToSize может быть оправдан. Для краткоживущего списка или активно изменяемого буфера стоимость сжатия часто важнее экономии памяти.