The IoC container and dependency injection

Without a container, an OrderService builds its own collaborators: new JdbcOrderRepository(new HikariDataSource(...)). The class decides which implementation it gets and how it is wired. Inversion of control turns that around: the class only declares what it needs, usually as constructor parameters, and something else — the Spring ApplicationContext — decides what to pass in. Handing a dependency in from outside is dependency injection; IoC is the broader idea that the framework, not your code, drives object creation.

@Service
public class OrderService {
    private final OrderRepository orders;
    private final Clock clock;

    // A single constructor needs no @Autowired: Spring uses it.
    public OrderService(OrderRepository orders, Clock clock) {
        this.orders = orders;
        this.clock = clock;
    }
}

@Configuration
class TimeConfig {
    @Bean
    Clock clock() { return Clock.systemUTC(); }
}

A bean is an object whose lifecycle the container manages. Spring finds bean definitions in two ways: component scanning picks up classes annotated @Component (or @Service, @Repository, @Controller, which are specialisations of it) in the package of the @SpringBootApplication class and below; and @Bean methods in @Configuration classes register whatever they return.

What happens at startup

When the context refreshes, it pre-instantiates every singleton bean (unless the bean is marked @Lazy). For each one it resolves the constructor arguments first, which means asking the container for those beans — creating them on the spot if they do not exist yet. Each singleton is created once, cached, and the cached instance is what every other bean receives. The model below is that algorithm in a few lines: definitions are visited in registration order, but dependencies are always built before the bean that needs them.

Why constructor injection

Field injection (@Autowired private OrderRepository orders;) works, but the object can exist with the field still null, the field cannot be final, and a unit test has to use reflection or a Spring context to set it. Constructor injection makes the dependencies explicit, lets them be final, and lets a test call new OrderService(fakeRepo, fixedClock) with no Spring at all.

It also surfaces design problems early. If A needs B in its constructor and B needs A, neither can be constructed first. The container detects the loop when it is asked for a bean that is already being created and fails the startup with a BeanCurrentlyInCreationException. Since Spring Boot 2.6, circular references are refused by default even with field injection (spring.main.allow-circular-references is false), so the honest fix is to break the cycle — usually by extracting the shared logic into a third bean.

When more than one bean fits

Injection is by type. If two beans implement PaymentGateway, asking for a PaymentGateway is ambiguous and startup fails with NoUniqueBeanDefinitionException. Mark one bean @Primary to make it the default, or put @Qualifier("stripe") on the injection point to name the one you want. Injecting receives all of them.