IoC and DI Explained: What Exactly Gets Inverted

This article is the conceptual turning point of the whole Spring kernel. The five articles before it taught you how to write code; this one changes who makes the decisions.

In plain words: every class you write needs other classes to work with it (an order service needs a stock repository, a payment client, a mail sender). The question was never "how do they collaborate" but "who supplies those collaborators". The classic answer is to new them yourself inside your code. The Spring answer is that you write only "I need a stock repository", and a dedicated object-butler — the container, i.e. the ApplicationContext object that builds, wires and shelves every bean at startup, waiting for you to pick one up — does the rest.

After this article you should be able to answer three questions:

• Which three concrete duties does IoC invert, and where do DI and DIP each sit?
• At which step of the assembly sequence do constructor, setter and field injection differ, and why is the constructor the official default?
• When A and B need each other, why can field injection survive while constructor injection only produces an error?

Look at this familiar piece of code — it works, until a requirement changes:

It "runs", yet it welds three concrete implementations into the business logic. Change one thing and three break:

• Want to switch to WeChat Pay? You must edit OrderService's fields and every related call site
• Want a fake stock repository in a unit test? Impossible — new MysqlStockRepository(...) runs the moment the object is constructed, so any test hits a real database
• Want the stock service to shard? Back to the business class you go

The root cause is not "ugly code"; it is that the decision of "which implementation to use" has been inverted. OrderService both "processes orders" and "decides which stock, which payment, which mail client" — two responsibilities crammed into one class, so a change on either side ripples into the other.

"Inversion of Control" sounds mystical, but it breaks down into three concrete things:

They share one idea: the initiative for creation and wiring moves from the user to an external container. The business class drops from "director + actor" to "actor only" — it no longer cares where its co-star comes from; it just declares "I need a stock repository" when needed.

IoC is the goal; dependency injection (DI) is the primary means. The same dependency can be injected three ways:

Interviews love to ask: "How do IoC and DIP relate?" The answer is clean: DIP is the design principle; IoC is one means of realizing it.

DIP has two inversions:

• High-level modules should not depend on low-level modules; both should depend on abstractions. OrderService (high level) should not stare at AlipayClient (low level); it should target the PayClient interface.
• Abstractions should not depend on details; details should depend on abstractions. The PayClient interface should not know Alipay's signing details — rather, AlipayClient implements the interface.

So the chain is: DIP says "depend on abstractions" → DI provides the mechanism to "inject a concrete implementation of that abstraction" → the IoC container decides "which implementation to inject at runtime". One line: the principle sets the direction, the container does the dirty work.

"Don't call us, we'll call you" is what a Hollywood casting director tells actors: stop phoning to ask if there is a role, show your ability, and we will reach out. The IoC container is that director. The animation above shows the whole sweep; the six cells below can be clicked one by one — cell ③ in particular explains something most people never think about: the creation order is not something you wrote.

Contrast this with the "service locator" pattern, where business code actively calls ctx.getBean(...) — that is "I phone the director", with lookup logic coupled into the class. DI is "the director calls me", and the class is unaware the container exists. Active lookup versus passive reception — that is inversion of control in its most direct form.

Many think DI is just "a few fewer new calls", but the container does far more:

A container is no panacea; all its power rests on the premise that objects need to be managed centrally. For the following, forcing one in is a burden:

The demo below shows dependency injection happening for real inside a container. Toggle the conditions and watch the wiring chain react (this one is a kernel lab; the parameter-driven sandbox that shows results instantly lives in Section 11):

Put the four styles on one coordinate system — horizontal: how testable; vertical: whether the dependency can still change after it is set. The choice becomes obvious at a glance. A unit test here means a small test you can run with plain new, without booting the application; a Mock is a stand-in dependency you fabricate to replace the real database or payment gateway.

The chart already shows which quadrant each style sits in. The harder half to remember is the other column: what each style does to you. Tables are easy to skim and hard to recall, so play one round instead — click a style on the left, then click what you think it costs you.

The three styles differ in when the wiring happens, which is the whole answer to "why can a field-injected object be born with nulls". The first experiment shows the cleanest case, constructor injection: the dependency is a parameter, so the object is complete the instant it exists.

The second switches to field injection — same beans, same chain, but assembly moves to after instantiation. Once you see the gap between "instance created" and "dependencies injected", you understand the source of every trap in Section 12.

The third is the most valuable cell: A needs B, B needs A, and both use constructor injection. You will watch the container give up at step four — because at that moment not even a half-built A exists, so there is no reference to lend anybody.

A circular dependency means two or more objects need each other: A holds B and B holds A. The three-level cache is the trio of Maps the container uses to break such cycles, and the crucial one is level three, singletonFactories — it does not store the object itself but a "pickup slip": a factory able to hand out an early, half-finished reference when someone urgently needs one.

Steps 2 and 3 of the animation are the entire story: instantiation (calling a constructor reflectively to get an empty shell) happens before population (filling the shell with dependencies). Field and setter injection both follow "shell first, contents later", so the shell can be lent out at step 3; constructor injection requires the contents to be arguments, so no shell ever exists and there is nothing to borrow.

Cache on versus off differs in exactly these two log sequences:

Everything so far is about how dependencies arrive. One more distinction matters: does the container hand out one instance of a type or many? That switch is scope — singleton (the default: one instance per container) or prototype (a fresh one per request).

First, see the stations a bean passes from birth to destruction, and where @PostConstruct (initialization callback) and @PreDestroy (destroy callback) land:

Switch the scope to prototype and the last station disappears: once the container hands a prototype over, it lets go completely.

Those two labs only cover singleton and prototype. Real applications add request and session on top, together with two traps of their own: a prototype's destroy callback never runs, and a request-scoped bean injected into a singleton is dead on arrival. The next lab turns "how many live instances exist right now" into a counter you can watch:

Now the question beginners get wrong most often: if I call getBean twice for the same UserService, do I get the same object? Change scope and @Lazy on the left; the right panel immediately shows the hashCode shape and the verdict.

The sandbox answers "what does each combination produce". The console below answers something different: what this container actually holds right now. Every response is computed by the real Java kernel running in your browser, so type boot first, then beans, and walk the claims of this article one command at a time:

Every entry in the first column can be pasted straight into a search box — do not paraphrase or shorten it:

Row three is the crash this article sees most often. Do not read the answer first — in the real stack below, click the frame you think is guilty; wrong picks come with an explanation too:

Compress the whole article into one contrast. You have been walking the left-hand road all along, just without seeing where its bill arrives.

This home-page-sized container demo deserves a few minutes. Flip the condition switches and notice that when a bean's condition fails, the error surfaces at the first downstream bean that needs it, not on the offender itself — which is exactly how the NoSuchBeanDefinitionException row in Section 12 comes to life.

Goal: produce and read the two errors from this article with your own hands. Note that we deliberately keep the container out of it:

Expected output (on JDK 17+ the NPE message names the missing variable for you):

Now let the container instantiate it — add a StockRepository bean and register the service — and the same business line works:

Done when: you can say out loud why @Autowired did nothing in the first version — because that object never went through the container's population step.

Three tiny edits, one variable at a time; record what you observe:

1. Convert the field injection above to constructor injection and still call new OrderService(). You will observe the compiler refusing outright with constructor OrderService in class OrderService cannot be applied to given types — the missing dependency is caught while you type, which is the dividend of the top-left quadrant.
2. Let AServiceImpl and BServiceImpl require each other through constructors. You will observe startup failing with The dependencies of some of the beans in the application context form a cycle plus an ASCII cycle diagram; switch one side to field injection and the three-level cache breaks the cycle immediately. Then replay the circular lab from Section 10 with caches OFF and watch even field injection collapse.
3. Annotate UserService with @Scope("prototype") and print the hashCode of getBean(UserService.class) from two places. You will observe two different hashes; remove the annotation and they match again — the Section 11 sandbox is the static version of exactly that pair.

Build a small three-injection-styles comparison project that turns this article's claims into runnable evidence.

• One interface PayClient with two implementations AlipayClient and WechatPayClient (each prints a line in its constructor so creation order is visible)
• Three business classes obtaining PayClient via constructor injection, setter injection and field injection respectively
• One main: boot an AnnotationConfigApplicationContext, print each class's hashCode and whether its dependency is null, then create the field-injected class with new to reproduce the NPE
• Finish by letting both implementations coexist, triggering NoUniqueBeanDefinitionException, and fixing it once with @Primary and once with @Qualifier to compare their reach

Acceptance checklist: ① the constructor-injected class is testable with plain JUnit + new, no Spring started; ② the field-injected class fails under the same test and you can name the step responsible; ③ you can explain "who creates the object" in three sentences a colleague understands.