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

reserveCapacity резервирует место минимум для указанного количества элементов, но не добавляет элементы и не изменяет count. Из этого нельзя заключать, что будет выделено ровно столько памяти, что дальнейшие операции никогда не вызовут аллокаций или что адрес внутреннего буфера останется неизменным.

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

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

reserveCapacity появился как средство заранее сообщить коллекции ожидаемый объём данных и уменьшить число потенциальных перераспределений памяти при последовательном наполнении массива.

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

Представим построение большого массива в цикле. Без резервирования Swift может несколько раз расширять хранилище, копируя или перемещая уже накопленные элементы. Это увеличивает пиковое потребление памяти и может ухудшить время выполнения.

Вызов reserveCapacity не создаёт логические элементы: после него count остаётся прежним. Кроме того, резервирование не отменяет копирование при срабатывании copy-on-write, если массив разделяет хранилище с другим значением.

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

Для Array вызов reserveCapacity(n) гарантирует наличие ёмкости как минимум для n элементов в подходящем внутреннем хранилище. Если текущей ёмкости достаточно, вызов может ничего не делать; если недостаточно, массив может заранее расширить хранилище.

var values: [Int] = []
values.reserveCapacity(3)

print(values.count) // 0
values.append(10)
values.append(20)
values.append(30)
print(values.count) // 3

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

При уникальном хранилище обычные добавления до зарезервированного количества не должны требовать расширения буфера из-за нехватки ёмкости. Но аллокация всё ещё возможна по другим причинам: например, при отделении общего хранилища в рамках copy-on-write.

Резервирование не гарантирует стабильность указателей на элементы. Любая операция, меняющая расположение данных или отделяющая хранилище, может сделать ранее полученный адрес недействительным. Поэтому reserveCapacity — оптимизация производительности, а не средство управления памятью на уровне ABI.

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

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

Можно передавать элементы через цепочку map и затем получать новый массив: это выразительно, но промежуточные результаты могут увеличить расход памяти. Можно вручную наполнять массив и вызвать reserveCapacity, если ожидаемый размер известен или надёжно оценён.

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

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

Меняет ли reserveCapacity количество элементов?

Нет. Метод меняет только доступную ёмкость внутреннего хранилища. count, индексы элементов и содержимое массива остаются прежними; зарезервированные позиции нельзя читать как существующие элементы.
Гарантирует ли reserveCapacity отсутствие копирования при добавлении элементов?

Нет, не во всех обстоятельствах. При совместно используемом хранилище copy-on-write изменяющая операция сначала должна создать уникальное хранилище. Кроме того, гарантия резервирования не распространяется на произвольные операции, которые могут изменить структуру хранения и требования к памяти.
Почему нельзя использовать reserveCapacity для сохранения адреса элемента?

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