This module built one thing, from many angles: the container — the part of Spring that creates your objects, wires them together, and hands them out. Eight articles each zoomed in on a different corner of it. This recap zooms back out. The goal here is not to re-explain each topic, but to show how they are all the same idea seen from different sides, so the whole module collapses into a picture you can hold in your head at once.

So before the details, here is the single sentence the entire module hangs on: the container is a factory that runs at startup, and almost every feature you met is just that factory doing a little extra work while it builds a bean. Keep that sentence close. Everything below is a way of filling it in.

The factory, in one picture

Picture an assembly line that runs exactly once, when your application boots. You hand it a list of what to build and how the pieces fit. It builds every object your app is made of, connects them, sets them on a shelf, and hands them out on request for the rest of the program's life.

That assembly line is the container. The objects it builds and manages are beans. An object you create yourself with new is not a bean — Spring never touched it — and that distinction is the thread running through every trap in this module.

The factory does four things at startup, and the order matters: it reads recipes, works out who needs whom, builds from the bottom up, and caches each result.

ApplicationContext ctx = SpringApplication.run(App.class, args);
OrderService svc = ctx.getBean(OrderService.class); // already built and wired

By the time run returns, the work is done. Asking for a bean is instant because the building already happened. Every other topic in the module is a detail about how that one startup pass works.

Why we hand the work over at all

The module opened with a question of control. Left alone, a class builds its own collaborators with new — and in doing so it welds together two unrelated decisions: what it needs, and which exact thing it gets and how that thing is built.

class OrderService {
    private final PaymentGateway gateway = new PaymentGateway(new HttpClient());
}

Pulling those two decisions apart is the whole point. The class should declare what it needs and let something outside choose and supply the which. Handing that choice to the framework is Inversion of Control — your code stops creating its own collaborators. The way the collaborator then arrives is Dependency Injection — it is passed in from outside.

@Service
class OrderService {
    private final PaymentGateway gateway;

    OrderService(PaymentGateway gateway) {   // declares the need, receives it
        this.gateway = gateway;
    }
}

IoC is the idea; DI is the delivery. And the delivery has a preferred form for a mechanical reason, not a stylistic one: constructor injection makes the field final, makes the object impossible to build half-wired, and makes it testable with a plain new in a unit test. That preference for the constructor is a decision the rest of the module keeps cashing in.

How a single bean comes to life

Once you accept that the factory builds your beans, the natural next question is how it builds one. The answer is a fixed four-stage sequence — the bean lifecycle:

1. Instantiate — construct the raw object.
2. Populate — inject field- and setter-style dependencies.
3. Initialize — run setup now that everything is wired.
4. Destroy — run teardown at an orderly shutdown.

The order is the lesson. A field-injected dependency is null if you touch it in the constructor, because populate (stage 2) has not run yet. Setup that needs dependencies belongs in @PostConstruct (stage 3), where wiring is guaranteed complete. Teardown mirrors it in @PreDestroy (stage 4).

Notice how this rewards constructor injection again: it folds populate into instantiate, so a constructor-injected bean is never half-there. The lifecycle is just the factory's per-bean routine, and most of its surprises come from forgetting which stage runs when.

How many, and how long

The lifecycle describes one bean's journey. Scope answers the other two questions about it: how many instances exist, and how long each lives.

• Singleton — one instance per container, the default, shared by everyone.
• Prototype — a fresh instance on every request, built on demand.
• Request and session — one instance per HTTP request or per user session.

"Shared," in the singleton line, is the dangerous word, and it leads to the module's most common bug. Because one singleton serves every thread at once, any mutable field on it is a race condition.

@Service
class CartService {
    private int itemCount;          // one field, every thread, lost updates
    void addItem() { itemCount++; }
}

The rule that falls out is short: keep singletons stateless. Immutable shared state — your injected dependencies — is exactly what a singleton is good at; mutable shared state is the trap.

Which container is doing all this

Up to here, "the container" has been a single idea. In Spring's code it wears two names, and the difference matters. BeanFactory is the minimal contract — store recipes, build beans lazily on request. ApplicationContext extends it and staffs it.

That staffing is the whole reason you always use the ApplicationContext. Features like @Autowired and @PostConstruct are not part of the factory core — each is a plugin called a BeanPostProcessor that gets a crack at every bean during the lifecycle. The bare BeanFactory registers none of them, so it silently ignores your annotations. The ApplicationContext registers them all automatically, and it builds singletons eagerly at startup — so a broken wiring fails at boot, on your machine, not three days later in production.

ApplicationContext ctx = new AnnotationConfigApplicationContext("com.shop");
// every annotation honored, every singleton already built

This is the same fail-fast instinct constructor injection showed with circular dependencies: surface the problem at the safest possible moment.

How you tell the factory what exists — and how it finds it

The factory needs recipes. Where they come from is the configuration style, and Spring has had three, each fixing the last one's pain:

• XML — all wiring in an external file. Central, but verbose and string-typed.
• Annotations — @Component and friends mark the class itself. The default for your own code.
• Java config — @Bean methods inside a @Configuration class. The way to register classes you cannot annotate, like third-party objects.

All three end as the same internal bean definitions, which is why one app mixes them freely. Java config carries one subtlety worth keeping: Spring wraps a @Configuration class in a proxy so that a call from one @Bean method to another returns the shared bean instead of building a second one.

For the annotation style, component scanning is how the factory actually finds your marked classes. @ComponentScan walks a base package and everything beneath it — and only ever downward, which is why the main class lives in the root package, and why a class above the scan's start point silently never registers. The stereotypes — @Service, @Repository, @Controller — are just @Component with a role attached, scanned identically, though @Repository earns exception translation as a bonus.

How the factory connects the beans

With every bean found and defined, the last job is wiring them — autowiring. The rule is resolution by type: the container finds the one bean whose type fits a dependency and injects it. One match and the wiring is silent.

The interesting part is the tie-break, when two beans fit one slot. The container refuses to guess and fails fast; you break the tie three ways:

• Parameter name — a quiet fallback that matches the injection point's name to a bean name.
• @Primary — one global default, declared on the bean.
• @Qualifier — a named choice at the injection point, which overrides @Primary.

And when a dependency might legitimately be absent, Optional<T> or ObjectProvider<T> make that explicit instead of crashing.

The two threads that run through everything

Step back and two ideas turn out to connect almost every topic.

The first is the proxy — a same-shaped stand-in the factory can hand you instead of the bare bean. It is not one feature; it is the same trick reused everywhere. It is how @Transactional opens a transaction around your method. It is how a request-scoped bean gets injected into a singleton — the proxy resolves to the right per-request instance on each call. It is how a @Configuration class avoids building a bean twice. And its timing — created after @PostConstruct runs — is why init code self-calling a proxied method quietly skips the wrapper. Once you see the proxy, a dozen "how does Spring even do that?" questions share one answer.

The second is fail-fast: surface a mistake at the earliest, safest moment. Eager singleton startup catches broken wiring at boot. Constructor injection turns a circular dependency into a boot-time error instead of a production StackOverflowError. An ambiguous autowire stops the app rather than picking the wrong bean. The strictness is the safety.

The traps, as one family

Almost every gotcha in this module is the same mistake wearing different clothes — a mismatch between when injection happens and when you use the result:

• A field-injected dependency touched in the constructor is null — populate runs after the constructor.
• A mutable field on a singleton races — one instance is wired once and shared across every thread.
• A prototype injected into a singleton freezes — injection is a one-time event, so you get one prototype forever; reach for ObjectProvider to pull a fresh one each call.
• A proxied method self-called inside @PostConstruct skips the proxy — the wrapper is not built yet.

See them together and they stop being four facts to memorize. They are all consequences of one truth: for a singleton, wiring happens exactly once, at startup.

The one picture to keep

If you keep only one thing from this module, keep the factory. The container reads recipes, builds your beans bottom-up in dependency order, can wrap each one in a proxy, caches the results, and fails fast when something does not fit. Inversion of Control is why you hand the work over; dependency injection is how the pieces arrive; the lifecycle is how one bean is assembled; scope is how many and how long; the ApplicationContext is the fully-staffed factory that runs it; configuration, scanning, and autowiring are how it learns what to build and connects it all.

Everything heavier you meet from here — AOP, transactions, web request handling, data access — is a variation on this one startup pass. The factory does not go away. It just keeps finding new work to do while it builds your beans.