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

OnceLock<T> гарантирует, что значение будет инициализировано однократно, а все потоки, получившие результат после завершения инициализации, увидят полностью записанное значение. Вызовы get_or_init при конкуренции используют внутреннюю синхронизацию: один поток выполняет инициализатор, остальные ждут его завершения или получают уже опубликованный результат.

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

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

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

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

Несколько рабочих потоков могут одновременно впервые запросить конфигурацию. Без корректной синхронизации два потока способны одновременно создать ресурс, а третий — увидеть состояние, в котором память уже выделена, но объект ещё не полностью сконструирован.

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

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

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

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

use std::sync::OnceLock;

static CONFIG: OnceLock<String> = OnceLock::new();

fn load_config() -> String {
    String::from("production")
}

fn config() -> &'static str {
    CONFIG.get_or_init(load_config).as_str()
}

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

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

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

В HTTP-сервисе несколько потоков впервые обрабатывают запросы и обращаются к общему парсеру конфигурации. Вариант с обычной глобальной переменной потребовал бы отдельного флага готовности и ручного контроля порядка публикации; ошибка в таком коде могла бы привести к гонке.

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

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

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

1. Достаточно ли OnceLock для публикации значения, которое содержит Cell<T>?

Нет, сама однократность инициализации не делает внутренний тип безопасным для совместного доступа. Если значение публикуется как общая ссылка из многопоточного контекста, его тип должен удовлетворять требованиям Sync; Cell<T> для такой публикации не подходит.

2. Запустится ли инициализатор get_or_init несколько раз при одновременных вызовах?

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

3. Защищает ли OnceLock<Vec<T>> от гонок при последующем изменении вектора?

Нет. OnceLock защищает только переход из состояния «не инициализировано» в состояние «значение опубликовано». Если после публикации вектор изменяется, доступ к нему должен быть организован отдельно, например через Mutex<Vec<T>>, RwLock<Vec<T>> или другой подходящий механизм синхронизации.