> Как реализовать паттерн singleton в Go? (Go)

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

Singleton в Go реализуется через sync.Once, который гарантирует однократную инициализацию при конкурентном доступе. Альтернатива - инициализация в init() или на уровне пакета, но это менее гибко. Основной паттерн: приватная переменная, публичная функция-геттер, внутри которой sync.Once.Do выполняет создание экземпляра. В Go часто предпочитают dependency injection вместо singleton, так как он усложняет тестирование и создаёт скрытые глобальные состояния.

Подробное объяснение

Классический singleton в Go - это не просто один экземпляр, а гарантия потокобезопасной ленивой инициализации. Основные подходы:

1. sync.Once - рекомендуемый способ. Он атомарно выполняет функцию инициализации ровно один раз, даже при параллельных вызовах. Это безопасно и просто.

2. Инициализация в init() - выполняется при загрузке пакета, до main(). Подходит, если создание объекта не зависит от внешних параметров. Минус - нет ленивости и сложно контролировать порядок.

3. Глобальная переменная - инициализируется при старте программы. Просто, но не лениво и не подходит для условной инициализации.

4. sync.Mutex + проверка - ручная реализация с double-checked locking. Работает, но избыточна, так как sync.Once решает ту же задачу надёжнее.

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

На практике

Для senior-позиции важно показать понимание trade-off. Если singleton оправдан (например, пул соединений, кэш, конфигурация), используй sync.Once. Если нет - предложи DI-контейнер или фабрику. Также стоит упомянуть, что в Go нет приватных конструкторов в классическом смысле, поэтому защита от создания второго экземпляра - это договорённость, а не жёсткое ограничение.

Пример кода

GO
package config

import "sync"

type Config struct {
    // поля конфигурации
}

var (
    instance *Config
    once     sync.Once
)

func GetConfig() *Config {
    once.Do(func() {
        instance = &Config{
            // инициализация
        }
    })
    return instance
}

Как отвечать на собеседовании

Начни с sync.Once как основного инструмента. Объясни, почему он предпочтителен: атомарность, ленивость, отсутствие гонок. Затем упомяни альтернативы и их ограничения. Покажи, что понимаешь, когда singleton уместен, а когда - нет. Для senior важно добавить: "Я бы использовал singleton только для инфраструктурных объектов, а для бизнес-логики - внедрение зависимостей". Если спросят про тестирование, скажи, что singleton можно мокать через интерфейс.

Что проверяет интервьюер

• Понимание конкурентности и sync.Once.
• Знание альтернатив и их trade-off.
• Умение критически оценивать паттерн, а не просто воспроизводить его.
• Способность связать решение с тестируемостью и архитектурой.
• Для senior - видение, когда singleton - это плохой выбор.

Типичные ошибки

• Использование мьютекса без необходимости, когда есть sync.Once.
• Инициализация в init() без понимания порядка загрузки пакетов.
• Возврат указателя на singleton без защиты от мутаций - это уже не singleton, а глобальное состояние.
• Забывают, что sync.Once не защищает от копирования структуры, если она содержит мьютекс.
• Утверждение, что singleton в Go - это всегда правильно, без анализа контекста.