DEV Community: Ankit Verma

Bean scopes (singleton/prototype/request/session) + singleton thread-safety gotcha

Ankit Verma — Mon, 08 Jun 2026 07:41:11 +0000

Every object the container builds has to answer two quiet questions: how many copies of it should exist, and how long should each one live? One shared copy for the whole application? A fresh one every time someone asks? One per web request? The answer to those two questions is the bean's scope.

You usually meet scope the day shared state misbehaves. A field on a @Service holds a value for one user and somehow shows up for another. Or you expected a brand-new object each time and kept getting the same one back. Both are scope surprises — and both have the same root cause once you can see it.

So this article walks the scopes Spring gives you, starting with the default you have been leaning on without ever naming it. Then it covers the two traps scope sets — including the one that causes real, hard-to-find production bugs.

The default you have already been using

Every bean in the previous articles was a singleton: the container builds exactly one instance, caches it at startup, and hands that same object to everyone who needs it, for the whole life of the application. You never asked for this. It is simply what @Component, @Service, and a bare @Bean give you.

@Service
class OrderService { }   // one instance, shared everywhere

Ask the container for it twice and you get the identical object back:

OrderService a = ctx.getBean(OrderService.class);
OrderService b = ctx.getBean(OrderService.class);
// a == b  → true, same instance

One word of caution on the name. A Spring singleton means one instance per container — not the classic JVM-wide singleton from design-pattern books. Spin up a second container and you get a second instance. Within one application that distinction rarely bites, but it is why "singleton" here is a scope, not a guarantee about the whole JVM.

Asking for a fresh one each time: prototype

Sometimes one shared instance is exactly wrong. You want a short-lived, stateful helper — a builder you fill in, use once, and throw away. For that, Spring offers the prototype scope: a brand-new instance every single time the bean is requested.

@Component
@Scope("prototype")
class ReportBuilder { }   // a new one on every request

Now each getBean hands back a different object:

ReportBuilder a = ctx.getBean(ReportBuilder.class);
ReportBuilder b = ctx.getBean(ReportBuilder.class);
// a != b  → two separate instances

Two more things change with prototype. The container builds it on demand, when you ask — not eagerly at startup like a singleton. And, as the lifecycle article noted, Spring runs a prototype's setup but then forgets it: it never calls the destroy stage. The container builds a prototype, hands it over, and walks away.

Why the default is a singleton — and the trap hiding inside it

One shared instance is cheap and fast, which is why it is the default. But "shared" is the dangerous word, and it leads straight to the single most common Spring bug.

A web application handles many requests at the same time, each on its own thread. Every one of those threads calls into the same singleton instance. So any mutable field on a singleton is shared across all of them at once:

@Service
class CartService {
    private int itemCount;          // ONE field, shared by every thread

    void addItem() { itemCount++; } // two threads here = lost updates
}

This looks fine in testing, where one request runs at a time. In production it corrupts data. Two users add items concurrently, both threads read itemCount, both increment, both write back — and one update vanishes. Worse, one user's count is now visible to another, because there was only ever one field.

The fix is a rule, not a trick: keep singletons stateless. Don't store per-call or per-user data in fields. Let that data live in method parameters, local variables, and return values — those sit on each thread's own stack, so they are never shared.

@Service
class CartService {
    int withItemAdded(int count) {   // state passed in and out, never stored
        return count + 1;
    }
}

Note what is not a problem: fields that are set once at construction and never change — your injected dependencies, anything final. Those are shared too, but since nobody mutates them, no thread can corrupt them. The bug is specifically mutable shared state. Immutable shared state is exactly what a singleton is good at.

Scopes that follow the web request

Sometimes you genuinely need per-user or per-request state, and stuffing it through method parameters everywhere gets ugly. For that, Spring adds two web-aware scopes.

A request-scoped bean lives for exactly one HTTP request: the container builds a fresh one when the request arrives and discards it when the response is sent. A session-scoped bean lives for one user's session, spanning their many requests until the session ends.

@Component
@RequestScope
class RequestContext {
    private String traceId;   // safe: each request gets its own instance
}

Because every request gets its own instance, that mutable traceId field is now perfectly safe — the sharing that doomed the singleton simply isn't there. This is the right home for "data that belongs to this one request."

But it raises an awkward question. A singleton is built once, at startup. A request-scoped bean does not exist yet at startup — no request is in flight. So how can you inject a request-scoped bean into a singleton, when the thing you want to inject won't exist until much later, and then keeps being replaced?

The scoped-proxy fix

This is where the proxy from the first article comes back to do real work. When you inject a shorter-lived bean into a longer-lived one, Spring does not inject the real bean — it injects a proxy: a same-shaped stand-in that, on every method call, looks up the correct instance for the current request and forwards to it.

@RequestScope switches this proxy on by default, so the injection just works:

@Service
class AuditService {
    private final RequestContext context;   // really a proxy, injected once

    AuditService(RequestContext context) {
        this.context = context;
    }

    void record(String event) {
        context.setTraceId(event);   // resolves to THIS request's instance
    }
}

The singleton AuditService is wired exactly once at startup, holding the proxy forever. But each call through that proxy lands on the right per-request RequestContext. Without the proxy you would be stuck: either a startup failure because no request exists to inject, or one shared instance that defeats the entire point of request scope. The proxy bridges the lifespans.

The prototype-in-singleton trap

Now the trap that catches almost everyone, because it fails silently rather than loudly. Inject a prototype into a singleton the obvious way, and you do not get a fresh prototype per call:

@Service
class InvoiceService {
    private final ReportBuilder builder;   // injected ONCE, frozen forever

    InvoiceService(ReportBuilder builder) {
        this.builder = builder;
    }

    void generate() {
        builder.reset();   // same instance every invoice — not what you wanted
    }
}

You chose prototype precisely so each invoice would get its own ReportBuilder. Instead you got exactly one, captured at startup, reused for the life of the app. The reason is simple once it clicks: injection is a one-time event for a singleton. Spring builds InvoiceService once, so it resolves and injects its dependencies once. The prototype scope only promises a new instance per request to the container — and that request happened a single time, at wiring.

The fix is to ask the container for a new one at the moment you need it, instead of capturing one at startup. ObjectProvider is the clean way to do exactly that:

@Service
class InvoiceService {
    private final ObjectProvider<ReportBuilder> builders;

    InvoiceService(ObjectProvider<ReportBuilder> builders) {
        this.builders = builders;
    }

    void generate() {
        ReportBuilder builder = builders.getObject();   // a fresh prototype each call
    }
}

Each getObject() is a new request to the container, so each returns a new prototype. (A scoped proxy on the prototype achieves the same thing transparently, the way @RequestScope did — but ObjectProvider makes the "give me a fresh one now" intent obvious at the call site.)

Putting it together

A scope answers two questions about a bean: how many instances exist, and how long each lives. Singleton — one per container, the default — is built once and shared by everyone. Prototype is a new instance on every request, built on demand, and never destroyed by the container. Request and session scope tie a bean's life to one HTTP request or one user's session.

Both traps in this article come from mixing lifespans. The thread-safety bug is one singleton shared across many threads at once, so any mutable field is a race — fixed by keeping singletons stateless. The stale-injection bug is a short-lived bean injected once into a long-lived one, so it freezes at startup — fixed by the scoped proxy, or by pulling a fresh instance from an ObjectProvider when you actually need it.

Hold on to the one idea underneath both: for a singleton, wiring happens exactly once. Everything that surprises you about scope follows from remembering when injection actually runs.

Bean lifecycle: instantiate populate init destroy

Ankit Verma — Mon, 08 Jun 2026 06:49:43 +0000

A Spring bean does not blink into existence fully formed. The container assembles it in a fixed order of stages — build the object, fill in its dependencies, run its setup, and much later, run its teardown. That ordered sequence is the bean lifecycle.

You meet it the first time you need something to happen at an exact moment. You want a connection pool opened after the bean has all its dependencies, but before it handles a single request. You want a cache flushed to disk when the app shuts down — but only if startup actually finished. To put your code in the right place, you have to know the order these stages run in, and what is guaranteed to be ready when each one fires.

The whole lifecycle is just the container doing work around an object it built. We will walk it end to end: the four main stages, the hooks Spring opens at each one, and two traps that fall straight out of the ordering.

The four stages, in one breath

Here is the spine of the whole article — the path every singleton bean walks, from startup to shutdown:

Instantiate — construct the raw object.
Populate — inject its dependencies.
Initialize — run setup now that it is fully wired.
Destroy — run teardown at shutdown.

Everything else is detail hung on those four pegs. Let's take them one at a time, because the order is the entire point — each stage is only safe to use once you know what ran before it.

Stage 1: instantiate — a bare object

First the container calls a constructor and gets back a raw Java object. Nothing Spring-specific has happened yet; this is the same new you would write by hand, just done for you.

@Component
class InventoryService {
    private final WarehouseClient client;

    InventoryService(WarehouseClient client) {   // constructor injection
        this.client = client;
    }
}

There is a subtlety worth pausing on. When you use constructor injection — dependencies passed as constructor arguments, as above — the wiring happens inside this first stage. Spring works out what WarehouseClient is, builds it, and hands it in as the object is created. For constructor-injected beans, "instantiate" and "populate" are the same moment.

That is not true for the other injection styles, and the difference is where the next stage earns its name.

Stage 2: populate — the fields get filled

If a dependency is injected into a field or through a setter, it cannot arrive in the constructor — the object has to exist first, then Spring reaches in and sets it. That second step is populate: the container assigns every field- and setter-injected dependency onto the freshly built object.

@Component
class InventoryService {
    @Autowired private WarehouseClient client;   // set during populate, not in the constructor
}

This ordering explains a bug everyone hits once. A field-injected dependency is null if you touch it inside the constructor:

@Component
class InventoryService {
    @Autowired private WarehouseClient client;

    InventoryService() {
        client.connect();   // NullPointerException — populate hasn't run yet
    }
}

The constructor runs in stage 1. Populate is stage 2. At the moment the constructor body executes, the field is still empty. This is one more reason the previous article pushed constructor injection so hard: it collapses these two stages into one, so a dependency is never half-there. But when you do use field or setter injection, populate is the stage that fills them — and nothing before it can rely on them.

Between populate and the next stage, Spring may also hand the bean a few references to the container itself, if the bean asks for them by implementing an Aware interface (for example BeanNameAware to learn its own bean name). It is a narrow feature you will rarely reach for, but it slots in right here: after the dependencies, before initialization.

Stage 3: initialize — the bean gets ready

Now the object is fully wired. This is the moment to do setup that needs the dependencies in place — open that connection pool, warm a cache, validate configuration. Spring calls this the initialization stage, and it gives you a hook that fires exactly here:

@Component
class InventoryService {
    private final WarehouseClient client;
    private Connection pool;

    InventoryService(WarehouseClient client) {
        this.client = client;
    }

    @PostConstruct
    void openPool() {
        this.pool = client.connect();   // every dependency is guaranteed wired by now
    }
}

The @PostConstruct method runs after populate, so it can lean on every dependency being present — the guarantee the constructor could not give you. This is the right home for "do this once, at startup, after wiring."

There are three ways to register init code, and when more than one is present they run in a fixed order:

A method annotated @PostConstruct — runs first. This is the standard, framework-agnostic choice.
afterPropertiesSet(), if the bean implements the InitializingBean interface — runs second. It couples your class to Spring's API, so it is rarely the better option.
A method named in @Bean(initMethod = "...") — runs last. Useful when the class is third-party and you cannot annotate it.

Reach for @PostConstruct unless you have a specific reason not to. The other two exist mostly for cases where you cannot put an annotation on the method.

The proxy slips in right after init

Remember from the first article that the container can wrap a bean in a proxy — a same-shaped stand-in that runs extra code (a transaction, an async hand-off) around your methods. The lifecycle is where that wrapping actually happens, and exactly when it happens is the source of a classic trap.

Spring exposes the init stage through an interface called BeanPostProcessor, which has two callbacks: one that runs before your init code, and one that runs after. The proxy is created in that second, after-init callback. So the order is:

Populate the bean.
Run your @PostConstruct / init methods — on the raw object.
Then wrap the result in a proxy and store that proxy in the container.

Read step 2 again, because it bites. Inside @PostConstruct, the proxy does not exist yet. The this you are holding is the bare bean. So if your init method calls one of its own proxied methods, the wrapper is skipped:

@PostConstruct
void warmUp() {
    this.reload();   // if reload() is @Transactional, there is NO transaction here
}

reload() may be annotated @Transactional, but calling it through this during init goes straight to the raw method — the proxy that would have opened the transaction has not been built yet. The fix is not to depend on proxied behavior from inside initialization. The lesson generalizes: your own init code always sees the unwrapped bean. Everyone else, fetching the bean from the container later, sees the proxy.

In service

Once initialization and any wrapping are done, the bean is finished. The container drops it on the shelf and hands out that same instance — the proxy, if there is one — to everyone who needs it, for the rest of the application's life. No more lifecycle events fire until shutdown. For a normal singleton, that "in service" period is essentially the whole life of the program.

Stage 4: destroy — teardown at shutdown

When the application context closes — a graceful shutdown, a SIGTERM, the JVM shutdown hook firing — Spring walks its singletons one last time and runs their teardown. This is the place to release what initialization acquired: close the pool, flush the buffer, deregister from a discovery service.

@PreDestroy
void closePool() {
    pool.close();   // mirror of @PostConstruct, run on the way down
}

Destruction mirrors initialization exactly, including the three-way ordering:

A method annotated @PreDestroy — runs first.
destroy(), if the bean implements DisposableBean — runs second.
A method named in @Bean(destroyMethod = "...") — runs last.

One honest caveat: these run only on an orderly shutdown, when Spring is given the chance to close the context. A hard kill — kill -9, a power loss — bypasses the whole stage. So @PreDestroy is the right place for a graceful flush, but it is not a guarantee that your teardown will ever run. Anything that absolutely must survive a crash needs to be durable by other means, not parked in a destroy callback.

The prototype trap

Everything above describes a singleton — the default, one shared instance the container holds and manages. Spring also offers the prototype scope, where you get a brand-new bean every time you ask for one. Prototypes go through the first three stages in full: Spring instantiates them, populates them, and runs their init callbacks.

Then it lets go. Spring does not run the destroy stage for prototype beans. It builds one, hands it to you, and forgets it ever existed — so @PreDestroy on a prototype is never called by the container.

That is a real leak waiting to happen. If a prototype opens a file handle or a socket in @PostConstruct, expecting @PreDestroy to close it, the close never fires and the resource leaks every time you request the bean. For a prototype that holds something which must be released, you are responsible for closing it yourself — the lifecycle only takes you halfway.

Putting it together

A bean is built in four ordered stages, and the order is the whole point. Instantiate makes the raw object — and for constructor injection, wires it at the same time. Populate fills in any field- and setter-injected dependencies, which is why those are null if you touch them too early. Initialize runs your setup once everything is wired, with @PostConstruct as the natural home. And destroy runs your teardown on an orderly shutdown, with @PreDestroy as its mirror.

Two traps fall straight out of that ordering. The proxy is built after your init code, so initialization always sees the unwrapped bean — self-calls to transactional or async methods quietly do nothing there. And prototypes get the first three stages but never the fourth, so anything they open, you must close.

Hold on to the shape rather than the annotations: wired, then ready, then — much later, and only if you shut down cleanly — gone.

Dependency Injection — the problem it solves

Ankit Verma — Mon, 08 Jun 2026 06:43:53 +0000

The first article in this module made one claim and moved on: stop calling new on your collaborators, and let the container hand them in. That was the what. This article is the why — because a rule you don't understand is a rule you'll break the first time it's inconvenient.

Dependency injection is the practice of giving an object the things it needs from the outside, instead of letting it build them itself. You met the name in passing already. Here we look at what it actually buys you, what it costs, and why one way of doing it is plainly better than the rest.

You hit this decision every time you write a class that needs another class. Do you reach for new and build the collaborator inside? Or do you ask for it and let something else supply it? That one choice, repeated across a codebase, is the difference between code you can test and change and code that quietly fights you.

The thing DI actually fights

It is tempting to think the enemy here is the new keyword. It isn't. The enemy is coupling to construction — a class deciding, inside its own body, exactly how its collaborators are built.

Look at what a class signs up for the moment it builds its own collaborator:

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

    void placeOrder(Order order) {
        gateway.charge(order.total());
    }
}

That one line welds together two decisions that have nothing to do with each other:

What OrderService needs — something that can charge money.
Which exact thing it gets, and how that thing is built — this concrete class, wired to Stripe, constructed just so.

The first decision is OrderService's business. The second is not. OrderService should not hold an opinion on whether payments go through Stripe or Adyen, or what a gateway needs underneath. The moment it bakes that opinion into code, the two decisions can never move apart again.

Pulling the two decisions apart

So separate them. Make OrderService depend only on the role — what it needs — and let it state that need without naming a concrete class:

interface PaymentGateway {
    void charge(Money amount);
}

@Service
class OrderService {
    private final PaymentGateway gateway;

    OrderService(PaymentGateway gateway) {   // "give me something that charges"
        this.gateway = gateway;
    }
}

OrderService now names an interface and nothing else. It has no idea which class shows up at runtime. Something outside decides that and supplies it.

The principle you just applied has a name: depend on abstractions, not on concrete implementations — and let an outside party choose and supply the concrete one. Dependency injection is simply the delivery mechanism for that idea. The interface is the contract; injection is how the chosen implementation arrives.

That separation is the whole payoff, and it shows up in three concrete ways.

You can test it. In a test you hand OrderService a fake gateway that records calls instead of hitting a bank — possible only because nothing concrete is baked in.

You can swap implementations. Moving from Stripe to Adyen in production means changing one bean definition. Not a single line of OrderService changes.

The container can wrap what it supplies. Because the gateway arrives from outside, the container gets a chance to hand you something that isn't your plain object — it can wrap it first. That wrap is how @Transactional and the other annotations from the last article attach themselves, and it is only possible because you didn't build the thing yourself.

How Spring picks what to inject

So OrderService asks for a PaymentGateway. How does the container know what to give it?

By type. When Spring builds OrderService and sees a constructor parameter of type PaymentGateway, it looks through the beans it knows about for one whose type fits PaymentGateway, and injects that one.

@Component
class StripeGateway implements PaymentGateway {
    public void charge(Money amount) { /* ... */ }
}

You never told Spring "use StripeGateway for OrderService." You declared a need by type, you have one bean of that type, and the container connected them.

What happens when two classes implement PaymentGateway — how you break the tie — is its own topic later in this module. For now the point is just this: resolution is by type.

Why the style of injection is not a matter of taste

There are three places Spring can put an injected dependency: the constructor, a setter, or straight into a field by reflection. They look interchangeable. They are not — and the difference is mechanical, not stylistic.

Here is the field version. It looks the cleanest and costs the most:

@Service
class OrderService {
    @Autowired private PaymentGateway gateway;   // looks tidy
}

Watch what this quietly allows. The object can be fully built while completely empty — new OrderService() succeeds and hands you an instance whose gateway is null. The field can't be final, so it stays mutable for the object's whole life. The only way to fill it is reflection, so you can't build a valid instance in a plain unit test without dragging Spring in. And the dependency is invisible from outside: nothing in the signature tells a caller this class even needs a gateway.

Now the constructor version:

@Service
class OrderService {
    private final PaymentGateway gateway;

    OrderService(PaymentGateway gateway) {
        this.gateway = gateway;
    }
}

Every one of those problems is gone — and not by convention, by language mechanics. The field is final, so it is set exactly once and the object is immutable after construction. There is no way to create the object without supplying its dependency; the compiler enforces it. And the dependency is right there in the signature for anyone to read.

The testing win becomes concrete the moment you write a test. No framework, no reflection — just a constructor call:

@Test
void chargesTheOrderTotal() {
    var gateway = new RecordingGateway();          // a fake, records instead of charging
    var service = new OrderService(gateway);       // plain Java, no Spring in sight

    service.placeOrder(new Order(Money.of(90)));

    assertThat(gateway.lastCharge()).isEqualTo(Money.of(90));
}

That last point hides the most useful one. Because every dependency has to pass through the constructor, a class with too many of them grows an ugly seven-argument constructor you can't ignore. Field injection lets the same class quietly pile up fifteen @Autowired fields and still look tidy. The constructor turns "this class is doing too much" from a hidden fact into a visible smell. That isn't a style preference — it is design feedback you would otherwise never get.

The circular-dependency trap

There is a sharper version of the same benefit, and it is worth seeing in full. Suppose A needs B, and B needs A — a circular dependency.

With field injection, Spring can often paper over it. It creates both raw objects first, then sets the fields afterward, so the cycle "works" by accident and ships. With constructor injection, neither object can be built before the other exists, so Spring can't even start — it fails at boot with BeanCurrentlyInCreationException.

It is tempting to read that as constructor injection being stricter and therefore more annoying. It is the opposite. The cycle is a real design flaw. Constructor injection forces you to see it the second you boot the app, instead of meeting it as a StackOverflowError in production weeks later. Failing fast, at the safest possible moment, is the feature.

Setter injection is the third style. It has one honest, narrow use: a genuinely optional dependency that can be reconfigured after the object exists. That is rare. Everywhere else, reach for the constructor.

One thing resolution-by-type gives you for free

Because injection is by type, a trick falls out that turns DI into a plugin system. Ask for a List of an interface, and Spring injects every bean that implements it:

interface ShippingRule {
    boolean applies(Order order);
    Money surcharge(Order order);
}

@Service
class ShippingCalculator {
    private final List<ShippingRule> rules;

    ShippingCalculator(List<ShippingRule> rules) {   // every ShippingRule bean, injected
        this.rules = rules;
    }

    Money totalSurcharge(Order order) {
        return rules.stream()
                    .filter(r -> r.applies(order))
                    .map(r -> r.surcharge(order))
                    .reduce(Money.ZERO, Money::add);
    }
}

Adding a new rule is now just adding one @Component that implements ShippingRule. ShippingCalculator never changes — it doesn't even know how many rules exist. That is the plugin pattern, delivered entirely by DI.

One trap rides along with it: the order of the beans in that injected list is not guaranteed unless you make it so. If your rules must run in a set sequence — a discount rule before a tax rule — relying on whatever order Spring happened to hand them in is a bug waiting for the day a refactor reshuffles them. Pin it with @Order on each implementation (or have them implement Ordered), and the list arrives in that order. (Ask for Map<String, ShippingRule> instead, and you get each implementation keyed by its bean name — handy when you need to pick one by name at runtime.)

Putting it together

Dependency injection isn't about dodging a keyword. It is about refusing to let a class decide both what it needs and which implementation it gets — and pulling those apart so the implementation can be swapped, centralized, and wrapped by the container.

Spring resolves the need by type. Constructor injection is the way to receive it — not for neatness, but because the language then guarantees your object is immutable, impossible to build half-wired, trivial to test without the framework, and honest about how many dependencies it really carries. And once injection is by type, the List-of-interface plugin pattern comes for free — just remember to pin the order when it matters.

Why Spring exists; the IoC container in one analogy

Ankit Verma — Mon, 08 Jun 2026 06:41:13 +0000

Spring is a framework that builds and connects the objects your application is made of. You write the classes. Spring creates them, wires them together, and hands them to each other at startup. That sounds like a small favor. It quietly reshapes how the whole codebase fits together, and almost every other Spring feature is built on top of it.

You meet this on day one, usually before anyone names it for you. You open a Spring project, find a class with no new anywhere in it, and wonder where its dependencies actually come from. The answer is the mechanism this article is about.

So this first piece is about why that job needs to exist at all, and the single mechanism Spring uses to do it. Once that mechanism is clear, most of Spring stops looking like magic.

Let's start with no Spring at all, and watch the problem show up on its own.

A class that builds its own tools

Here is a class that needs another class to do its job. The natural instinct is to build what it needs, right where it needs it, with new:

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

    void placeOrder(Order order) {
        gateway.charge(order.total());
    }
}

Look at what OrderService now owns. It places orders — that is its real job. But it also knows how to build a PaymentGateway. And because a gateway needs an HttpClient, it builds that too. One class doing two jobs: its actual work, and the plumbing underneath it.

That second job is where the trouble starts. It costs you three concrete things, and each one points to what comes next.

You can't test it in isolation. The real PaymentGateway calls a real bank. It is baked in with new, so there is no way to slip a fake one in for a test. To test the order logic, you'd have to charge actual money.

The plumbing gets copied everywhere. Every class that needs a gateway writes the same new PaymentGateway(new HttpClient()). Change how a gateway is built, and you have to hunt down every copy.

There is nowhere to add shared behavior. Suppose you want every payment wrapped in a database transaction. With the gateway hard-wired by new, there is no single seam to hook that in.

Handing over control

Now the same class, written the way Spring wants it. It stops building anything. It just states what it needs:

@Service
class OrderService {
    private final PaymentGateway gateway;

    OrderService(PaymentGateway gateway) {   // "I need a PaymentGateway"
        this.gateway = gateway;              // someone hands one in
    }
}

OrderService no longer knows or cares how a PaymentGateway is built. It declares the need in its constructor and trusts that a finished one will arrive from outside.

That flip has a name. Normally your code is in control of creating its own collaborators. Here, your code gives that control away — something else creates the objects and supplies them. Handing that control to the framework is called Inversion of Control, or IoC. The "control" is specifically control over creating and wiring objects. The "inversion" is that it now runs the other way around: the framework builds your objects and calls into them, instead of your objects building everything themselves.

The way the gateway actually arrives — through the constructor above — has its own name: Dependency Injection, or DI. The dependency, the gateway, is injected into OrderService from outside. It can arrive through a constructor, through a setter, or straight into a field. Prefer the constructor: the dependency is visible right there in the signature, and the field can be final, so the object is complete the moment it exists.

So IoC is the idea — your code no longer creates its own collaborators. DI is the delivery — how each collaborator gets in. Which raises the obvious question: who actually does the creating and the handing-over?

The container: a factory that runs at startup

The thing that creates and wires your objects is the container. In Spring it is an object called the ApplicationContext.

Here is the one analogy worth holding onto: the container is a factory. Not "factory" in the design-pattern sense — picture a literal assembly line that runs once, when your application starts. You hand it a list of what to build and how the pieces fit together. It produces every finished, connected object your app is made of, sets them on a shelf, and hands them out on request for the rest of the program's life. Everything below is just detail about how that factory runs.

Two small words have been quietly working and now deserve a definition. To wire two objects is just to give one a reference to the other — to set OrderService's gateway field to a real PaymentGateway instance, so the call inside placeOrder has something to land on. And a bean is simply an object that the factory creates and manages for you. Your @Service, your @Component, the things Spring builds — those are beans. An object you build yourself with new is not a bean, because Spring never touched it. That distinction looks small now; it matters in a minute.

Here is what the factory does, in order:

It scans your code and writes down recipes, not objects. When Spring sees @Component, @Service, or a method marked @Bean, it does not build anything yet. It records a bean definition: which class, how many copies to make, what that bean depends on, and any startup hooks. Think of it as a recipe card, not the finished dish.
It works out the dependency graph. From those recipes it figures out who needs whom. OrderService needs PaymentGateway, which needs HttpClient. A short chain here; in a real app, a wide web.
It builds the objects bottom-up. You can't inject a PaymentGateway before it exists, so Spring builds the leaves of the graph first and works upward, passing each finished bean into the next one's constructor.
It caches each finished bean and reuses it. Once a bean is built, the container keeps it and hands out that same instance to everyone who needs it. It does not build a fresh one each time.

That third step is worth making concrete, because the order is the whole point. Take the chain from earlier: OrderService needs a PaymentGateway, which needs an HttpClient. The factory cannot build OrderService first — it has nothing to put in the constructor yet. So it walks the chain from the bottom:

Build HttpClient. It depends on nothing, so it is a leaf and goes first.
Build PaymentGateway, passing in the HttpClient from step 1.
Build OrderService, passing in the PaymentGateway from step 2.

Three objects, built in the one order that lets each constructor receive a finished dependency. You never wrote a line of that sequencing. The factory read it off the graph and did it for you — and the same logic scales from this three-link chain to a graph with thousands of beans.

By the time startup finishes, every bean exists and every dependency is in place. Asking for one is now instant, because the work already happened:

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

The extra move: wrapping a bean in a proxy

There is one more thing the factory can do while it builds a bean, and it explains a surprising amount of Spring. While assembling a bean, the container can wrap it in a proxy before handing it over.

A proxy is a stand-in object. It looks exactly like your bean — same type, same methods — but it runs a little extra code before and after each call, then forwards to your real object. Callers cannot tell the difference. They think they are holding your bean directly.

That one trick is the real answer to a whole family of "how does Spring even do that?" questions:

@Transactional works because the proxy opens a database transaction before your method runs, and commits it after the method returns.
@Async works because the proxy hands your call off to run on another thread.
Security and caching annotations work the same way — extra code wrapped neatly around your untouched method.

This is also the seam the third cost was missing earlier. Back when OrderService built its own gateway with new, there was nowhere to slip in "wrap every payment in a transaction." Now there is: the gateway arrives from the factory, so the factory gets one chance, at build time, to hand back a wrapped version instead of the bare one. You wrote a plain method; the container wrapped it at startup. Hold on to this frame, because it keeps paying off: most Spring features are just the container doing extra work while it assembles your beans.

The one rule that ties it together

All of this only works on objects the container built. The moment you build one yourself, none of it happens:

OrderService svc = new OrderService(); // built by you, not Spring
// no gateway injected — Spring never saw this object

The usual symptom is a NullPointerException on a field you were sure Spring would fill in. Spring did not create the object, so it never wired it, and the field stayed null.

The same bypass quietly kills proxies. Call a @Transactional method on a hand-built instance, and there is no proxy around it, so no transaction ever starts. Nothing errors. The transaction simply isn't there. This is exactly why the bean-versus-new distinction from earlier mattered: Spring's powers ride on objects the factory made, and skip everything it didn't.

So the rule is short: if you want any of Spring's powers on an object, let Spring create the object. Don't new your beans.

Putting it together

Spring exists to take one job off your code: creating and connecting objects. Hand that job over, and three ideas fall out of it.

Inversion of Control is the handover itself — your code stops creating its own collaborators. Dependency injection is how those collaborators arrive, best through the constructor. And the container is the factory that does the work: it reads your recipes at startup, builds the objects in dependency order, caches them, and can quietly wrap each one in a proxy on the way out.

That last move, the proxy, is why so much of Spring feels like magic later. It isn't magic. It is the factory doing extra work as it builds your beans. Bean scopes, AOP, transactions — everything heavier you meet from here is a variation on this one startup pass.