Когда стоит использовать Eager инициализацию Bean в Spring?

Когда использовать Eager инициализацию Bean в Spring

В Spring по умолчанию используется Lazy initialization для singleton бинов (создаются при первом обращении). Eager initialization (по умолчанию) — это создание бина при старте ApplicationContext. Вот когда это критично:

1. Обнаружение ошибок конфигурации при старте

Зачастую проблемы с конфигурацией выявляются только при первом обращении к бину:

// ПЛОХО: ошибка конфигурации скроется до production
@Configuration
public class BadConfig {
    @Bean
    @Lazy // Ошибка будет обнаружена только при первом запросе
    public DataSource dataSource() {
        // Неправильная строка подключения
        String wrongUrl = environment.getProperty("db.wrong.property");
        return createDataSource(wrongUrl); // NPE при инициализации
    }
}

// ХОРОШО: ошибка упадет при старте приложения
@Configuration
public class GoodConfig {
    @Bean
    // Eager initialization (default) для singleton
    public DataSource dataSource() {
        String url = environment.getProperty("db.url");
        if (url == null) {
            throw new IllegalStateException("db.url not configured");
        }
        return createDataSource(url);
    }
}

// Запуск теста покажет ошибку сразу
// ApplicationContext context = new ClassPathXmlApplicationContext("config.xml");
// Exception in thread "main": IllegalStateException: db.url not configured

2. Критичные ресурсы, которые должны быть инициализированы в начале

Для сервисов, которые ОБЯЗАНЫ работать при старте:

@Configuration
public class CriticalResourcesConfig {
    
    // Кэш, который нужен с самого начала
    @Bean
    public CacheManager cacheManager() {
        // Warm up кэш при старте
        CacheManager manager = new ConcurrentHashMapCacheManager();
        manager.loadInitialData(); // Этот вызов ДО первого запроса
        return manager;
    }
    
    // Подключение к критичной БД
    @Bean
    public PrimaryDataSource primaryDb() {
        DataSource ds = new HikariDataSource(hikariConfig);
        // Проверяем соединение сразу
        ds.validate();
        return ds;
    }
    
    // Лицензия системы
    @Bean
    public LicenseValidator licenseValidator() throws InvalidLicenseException {
        LicenseValidator validator = new LicenseValidator();
        validator.validate(); // Если лицензия не валидна, стартуем прямо с ошибкой
        return validator;
    }
}

3. Bean зависит от других бинов, которые нужно инициализировать

У Spring есть механизм для разрешения зависимостей, но при lazy init это может быть неявно:

@Configuration
public class DependencyConfig {
    
    // Без явной инициализации порядок может быть неопределен
    @Bean
    @Lazy
    public ServiceA serviceA(ServiceB serviceB) {
        // serviceB инициализируется только при обращении к serviceA
        return new ServiceA(serviceB);
    }
    
    @Bean
    @Lazy
    public ServiceB serviceB(ServiceC serviceC) {
        return new ServiceB(serviceC);
    }
    
    @Bean
    @Lazy
    public ServiceC serviceC() {
        return new ServiceC();
    }
}

// ПРАВИЛЬНО: управляем порядком инициализации
@Configuration
public class OrderedDependencyConfig {
    
    // Eager init гарантирует, что все зависимости инициализируются
    @Bean
    public ServiceC serviceC() {
        System.out.println("ServiceC initialized"); // 1st
        return new ServiceC();
    }
    
    @Bean
    public ServiceB serviceB(ServiceC serviceC) {
        System.out.println("ServiceB initialized"); // 2nd
        return new ServiceB(serviceC);
    }
    
    @Bean
    public ServiceA serviceA(ServiceB serviceB) {
        System.out.println("ServiceA initialized"); // 3rd
        return new ServiceA(serviceB);
    }
}

4. Валидация конфигурации перед обработкой запросов

Для высоконадежных систем нужна гарантия, что все настроено правильно:

@Configuration
public class ValidationConfig {
    
    @Bean
    public ConfigurationValidator configValidator(Environment env) {
        ConfigurationValidator validator = new ConfigurationValidator();
        
        // Проверяем все обязательные properties при старте
        validator.assertProperty(env, "api.key");
        validator.assertProperty(env, "api.secret");
        validator.assertProperty(env, "db.host");
        validator.assertProperty(env, "db.port");
        validator.assertNumericProperty(env, "server.threads");
        
        // Если что-то не так, ApplicationContext не стартует
        validator.validate();
        return validator;
    }
    
    @Bean
    public HealthCheckService healthCheck(
        ConfigurationValidator validator,
        PrimaryDataSource db,
        CacheManager cache
    ) {
        // Все зависимости инициализированы и валидированы
        HealthCheckService service = new HealthCheckService(db, cache);
        service.runStartupChecks(); // Диагностика при старте
        return service;
    }
}

5. Event listeners и инициализаторы

Для выполнения инициализационной логики:

@Component
public class ApplicationStartupListener implements ApplicationListener<ContextRefreshedEvent> {
    
    @Autowired
    private UserRepository userRepository;
    
    @Autowired
    private CacheService cacheService;
    
    @Override
    public void onApplicationEvent(ContextRefreshedEvent event) {
        // Выполняется ОДИН раз после инициализации всех бинов
        
        // Warm up кэш
        List<User> users = userRepository.findAll();
        users.forEach(user -> cacheService.put(user.getId(), user));
        
        log.info("Loaded {} users into cache", users.size());
    }
}

// Альтернатива с ObjectFactory
@Component
public class DataInitializer {
    
    @Autowired
    private ObjectFactory<UserService> userServiceFactory;
    
    @PostConstruct
    public void init() {
        // Вызывается при инициализации этого бина
        userServiceFactory.getObject().initializeDatabase();
    }
}

6. Production-ready требования

Для критичных приложений нужна гарантия инициализации:

@SpringBootApplication
public class ECommerceApp {
    
    public static void main(String[] args) {
        SpringApplication app = new SpringApplication(ECommerceApp.class);
        
        // Стоп при ошибке инициализации (не continue с broken state)
        app.setAdditionalProfiles("production");
        
        ApplicationContext context = app.run(args);
        
        // К этому моменту ВСЕ критичные бины инициализированы и работают
        // Если что-то сломано, приложение не поднялось
    }
}

@Configuration
public class ProductionConfig {
    
    @Bean
    public DatabaseHealthCheck dbHealthCheck(DataSource ds) {
        // Запускается при старте
        DatabaseHealthCheck check = new DatabaseHealthCheck(ds);
        check.performFullDiagnostics();
        return check;
    }
    
    @Bean
    public SecurityValidator securityValidator(Environment env) {
        // Проверяем SSL certificates
        SecurityValidator validator = new SecurityValidator();
        validator.validateSSL(env.getProperty("ssl.cert.path"));
        return validator;
    }
}

Когда использовать @Lazy

Ленивая инициализация имеет смысл для:

@Configuration
public class OptionalComponentsConfig {
    
    // Редко используемый компонент
    @Bean
    @Lazy
    public PDFGenerator pdfGenerator() {
        return new PDFGenerator(); // Инициализируется только при первом обращении
    }
    
    // Тяжелый компонент, который может вообще не понадобиться
    @Bean
    @Lazy
    public MachineLearningModel mlModel() {
        return new MachineLearningModel(); // Загружает большой файл только если используется
    }
    
    // Optional интеграция
    @Bean
    @Lazy
    public SlackNotifier slackNotifier() {
        return new SlackNotifier(); // Только если Slack используется
    }
}

Итоговая рекомендация

Используй Eager initialization (default) для:

• Критичных сервисов (БД, кэш, лицензия)
• Валидации конфигурации
• Компонентов с чувствительными зависимостями
• Production-ready приложений

Используй @Lazy для:

• Опциональных/редко используемых компонентов
• Тяжелых ресурсов, которые могут вообще не понадобиться
• Микрооптимизации startup time (нечасто оправдано)

В большинстве современных приложений default Eager initialization это правильный выбор для надежности.