Как Spring определяет, какие бины нужно создать

# Как Spring определяет, какие бины нужно создать

Это один из самых важных механизмов Spring Framework. За 10+ лет я глубоко разобрался в том, как контейнер Spring работает под капотом. Объясню пошагово.

Основная идея: Dependency Injection Container

Spring — это контейнер, который управляет жизненным циклом объектов (бинов). Его главная задача:

1. Обнаружить какие классы нужны
2. Создать их экземпляры
3. Подключить зависимости

Способ 1: Component Scanning (аннотации)

Самый современный и удобный подход:

// Где-то в конфиге:
@SpringBootApplication
public class Application {
    public static void main(String[] args) {
        SpringApplication.run(Application.class, args);
    }
}

// @SpringBootApplication = @Configuration + @ComponentScan + @EnableAutoConfiguration

Spring сканирует пакет приложения и ищет классы с аннотациями:

// Spring найдёт это
@Component
public class EmailService {
    public void send(String email) {
        // отправка
    }
}

// Специализированные версии @Component:
@Service
public class UserService {
    // бизнес-логика
}

@Repository
public class UserRepository {
    // доступ в БД
}

@Controller
public class UserController {
    // обработка запросов
}

@RestController
public class ApiController {
    // REST API
}

Как это работает?

@ComponentScan(basePackages = "com.example.app")
public class AppConfig {
}

Spring:

1. Сканирует все классы в com.example.app и подпакетах
2. Ищет классы с @Component (или его наследниками)
3. Регистрирует их в контексте как бины
4. Определяет зависимости через конструкторы, setters, полей

private static final Logger log = LoggerFactory.getLogger(UserService.class);

// Spring будет вводить зависимости
@Service
public class UserService {
    private final UserRepository repo;  // Нужна зависимость
    private final EmailService email;   // Нужна зависимость
    
    // Constructor injection (рекомендуемый способ)
    public UserService(UserRepository repo, EmailService email) {
        this.repo = repo;
        this.email = email;
    }
}

Spring видит конструктор и ищет бины типов UserRepository и EmailService. Если найдёт — создаст их и передаст.

Способ 2: Явная конфигурация через @Bean

Для сложных сценариев или внешних либ:

@Configuration
public class AppConfig {
    
    // Spring создаст этот объект и зарегистрирует как бин
    @Bean
    public UserRepository userRepository() {
        return new UserRepository();
    }
    
    // Можно вводить другие бины в параметры
    @Bean
    public UserService userService(UserRepository repo, EmailService email) {
        return new UserService(repo, email);
    }
    
    // Для внешних либ
    @Bean
    public RestTemplate restTemplate() {
        return new RestTemplate();
    }
}

Этот способ даёт полный контроль. Я использую его когда:

• Нужна настройка перед созданием
• Это внешняя библиотека
• Нужна условная регистрация

@Configuration
public class ConditionalConfig {
    
    @Bean
    @ConditionalOnMissingBean  // Создай, если нет другого
    public EmailService emailService() {
        return new EmailService();
    }
    
    @Bean
    @ConditionalOnProperty(name = "app.cache.enabled", havingValue = "true")
    public CacheManager cacheManager() {
        return new RedisCacheManager();
    }
}

Способ 3: XML конфигурация (старинный способ)

Сейчас редко используется, но нужно знать:

<!-- application.xml -->
<beans>
    <bean id="userRepository" class="com.example.UserRepository" />
    
    <bean id="userService" class="com.example.UserService">
        <constructor-arg ref="userRepository" />
    </bean>
</beans>

А в Java:

public class Application {
    public static void main(String[] args) {
        ClassPathXmlApplicationContext context = 
            new ClassPathXmlApplicationContext("application.xml");
        UserService service = context.getBean(UserService.class);
    }
}

Способ 4: Spring Boot Auto-Configuration

Этот магический механизм:

// Внутри spring-boot-autoconfigure.jar
@Configuration
@ConditionalOnClass(DataSource.class)
public class DataSourceAutoConfiguration {
    
    @Bean
    @ConditionalOnMissingBean
    public DataSource dataSource() {
        // Создаёт DataSource на основе properties
        return createDataSource();
    }
}

Kогда ты добавляешь зависимость:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-jpa</artifactId>
</dependency>

Spring Boot автоматически:

1. Находит DataSourceAutoConfiguration (в META-INF/spring.factories)
2. Видит условия @ConditionalOnClass(DataSource.class) — они выполнены
3. Создаёт необходимые бины (DataSource, EntityManager и т.д.)

Порядок создания бинов

1. Scanning — найти все кандидаты
2. Registration — зарегистрировать определения
3. Dependency Resolution — найти зависимости
4. Instantiation — создать объекты
5. Injection — внедрить зависимости
6. Initialization — вызвать @PostConstruct

@Service
public class UserService implements InitializingBean {
    private final UserRepository repo;
    
    public UserService(UserRepository repo) {
        this.repo = repo;  // 5. Внедрение
    }
    
    @PostConstruct
    public void init() {
        // 6. Инициализация
        log.info("UserService initialized");
    }
    
    @PreDestroy
    public void destroy() {
        // Вызывается при shutdown
        log.info("UserService destroyed");
    }
}

Циклические зависимости

Заразу Spring может не справиться:

// ❌ Циклическая зависимость
@Service
public class ServiceA {
    private final ServiceB serviceB;
    public ServiceA(ServiceB serviceB) { this.serviceB = serviceB; }
}

@Service
public class ServiceB {
    private final ServiceA serviceA;
    public ServiceB(ServiceA serviceA) { this.serviceA = serviceA; }
}

Решение — использовать Field Injection или Setter Injection:

@Service
public class ServiceA {
    @Autowired  // Внедрение после создания
    private ServiceB serviceB;
}

@Service
public class ServiceB {
    @Autowired
    private ServiceA serviceA;
}

Практика: лучше переструктурировать код, чтобы избежать циклов. Это признак неправильной архитектуры.

Отладка

Увидеть все созданные бины:

@SpringBootApplication
public class Application {
    public static void main(String[] args) {
        var ctx = SpringApplication.run(Application.class, args);
        
        // Все бины
        String[] names = ctx.getBeanDefinitionNames();
        for (String name : names) {
            System.out.println(name + ": " + ctx.getBean(name).getClass());
        }
    }
}

В логах (при debug level):

Spring Boot properties (application.yml): yes
Component scanning: com.example.app
AutoConfiguration candidates: 50 total
AutoConfiguration report to stdout: info

Итого

Spring определяет бины через:

1. @Component + Component Scanning (90% cases) — мой выбор
2. @Bean в @Configuration (внешние либы, сложная логика)
3. Auto-Configuration (Spring Boot магия)
4. XML (legacy код)

В реальных проектах я применяю комбинацию: основные сервисы через @Service/@Repository, внешние либы через @Bean в отдельных конфигах, и Spring Boot автоконфиг для стандартных компонентов.