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

Начиная с C++11, инициализация локальной переменной static выполняется ровно один раз, даже если несколько потоков одновременно впервые вошли в функцию. Остальные потоки не используют объект до завершения его инициализации и после этого видят полностью инициализированное состояние.

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

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

До появления стандартной модели многопоточности C++ безопасная инициализация локальных статических объектов не имела единой переносимой гарантии для многопоточных программ. Разработчикам приходилось самостоятельно защищать проверку и создание объекта мьютексом или использовать нестандартные средства компилятора.

В C++11 стандарт формализовал модель памяти и одновременно закрепил потокобезопасную инициализацию локальных static. Это решило распространённую проблему ленивого создания объекта без необходимости вручную писать двойную проверку и синхронизацию.

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

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

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

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

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

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

Пример:

struct Config {
    int limit;
};

Config load_config() {
    return Config{42};
}

Config& config() {
    static Config value = load_config();
    return value;
}

Вызовы config() из разных потоков безопасно создают value только один раз. Однако обращение к value.limit после этого безопасно лишь для чтения либо при наличии отдельной синхронизации для изменений.

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

Альтернатива — явный std::call_once с std::once_flag. Она удобна, когда нужно инициализировать не локальный static, а произвольное состояние или управлять несколькими действиями. Локальный static обычно проще, но скрывает момент инициализации и связывает время жизни объекта с временем жизни программы.

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

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

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

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

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

Защищает ли локальный static все последующие обращения к объекту?

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

Что происходит с потоками, одновременно вошедшими в функцию во время инициализации?

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

Можно ли безопасно вернуть ссылку на локальный static из фонового потока до завершения main?

Только пока объект гарантированно жив и соблюдены правила доступа к его состоянию. Локальный static обычно уничтожается при завершении программы, и порядок разрушения разных статических объектов может стать проблемой. Нужно дождаться завершения фоновых потоков до разрушения объекта и не хранить ссылку, используемую после окончания его времени жизни.