Core

IoC, DI, Bean Lifecycle, AOP

The fundamentals that underpin everything else. The concepts people half-remember and trip over in interviews.

Foundation

Inversion of Control

What IoC Means

You describe what you need, the container provides it. You don't create dependencies — the framework creates them and hands them to you. That's the inversion: control of object creation moves from your code to the framework.

Why It Matters

Testability — swap real implementations for mocks without changing the class
Loose coupling — classes depend on interfaces, not concrete implementations
No manual wiring — the container resolves the dependency graph for you

ApplicationContext vs BeanFactory

BeanFactory is the low-level container. ApplicationContext extends it and adds event publishing, i18n, and annotation support. In practice, you always use ApplicationContext — just know that BeanFactory exists under it.

Before vs After IoC

Without IoC

With IoC

UserService svc =
  new UserService(
    new UserRepository(
      new DataSource(...)));

You manage every object manually. Change one constructor → fix every call site.

@Service
class UserService {
  private final UserRepository repo;
  // Spring injects automatically
  UserService(UserRepository repo) {
    this.repo = repo;
  }
}

Spring creates and wires everything. You declare the dependency; the container resolves it.

Wiring

Dependency Injection

Three Injection Styles

Style	How	When to Use
Constructor injection	`final` field + constructor arg	Always — preferred
Setter injection	`@Autowired` on setter	Optional dependencies only
Field injection	`@Autowired` on field	Never in production

Why constructor injection wins: immutability (final fields), explicit dependencies (all required deps visible in one place), and testability — you can test with plain new, no Spring context needed.

Things to Know

@Autowired is optional on constructors when there's only one constructor (Spring 4.3+)
@Qualifier — disambiguates when you have two beans of the same type
@Primary — marks one bean as the default when multiple candidates exist

Lifecycle

Bean Scopes

The 5 Scopes

Scope	Instance	Typical Use
`singleton`	One per container (default)	Stateless services, repositories
`prototype`	New per injection point	Stateful helpers
`request`	One per HTTP request	Web: request-scoped data
`session`	One per HTTP session	Web: user session state
`application`	One per ServletContext	Rarely used

The singleton trap: Injecting a prototype-scoped bean into a singleton doesn't work as expected — the singleton holds one reference forever. The prototype is created once at injection time, never again. Fix: use ApplicationContext.getBean() or @Lookup to get a fresh instance each time.

Lifecycle

Bean Lifecycle

The full sequence from birth to destruction:

Bean Lifecycle Rail

Instantiate

Inject Deps

Aware Callbacks

@PostConstruct

In Use

@PreDestroy

Destroyed

What You Actually Use

@PostConstruct — runs after injection. Use for init logic (loading caches, validating config).
@PreDestroy — runs before shutdown. Use for cleanup (closing connections, flushing buffers).
BeanPostProcessor — how Spring itself creates proxies. Runs on every bean. This is how @Transactional and @Cacheable get their proxy wrappers.

Cross-Cutting

AOP — Aspect-Oriented Programming

What Problem AOP Solves

Cross-cutting concerns — logging, transactions, security — applied consistently without polluting every business method. You define the logic once; Spring weaves it in via proxies.

The Vocabulary

Term	Definition
Aspect	The class containing the cross-cutting logic
Joinpoint	A point in execution (in Spring: always a method call)
Pointcut	The expression that selects which joinpoints to intercept
Advice	The code that runs — Before / After / Around

Around Advice

@Around is the most powerful — it wraps the method and controls whether to proceed. The @Transactional annotation is itself an AOP aspect — this is why it feels like magic.

Proxy Interception Flow

Pitfalls

Common Gotchas

Gotcha 1: Self-invocation bypasses AOP
Calling a @Transactional method from within the same class doesn't go through the proxy — the transaction never starts. The fix: extract the method to a separate bean, or inject the proxy via self reference.

Gotcha 2: Field injection in tests
Field-injected beans require the Spring context to instantiate. Constructor-injected beans can be tested with plain new. This is the real cost of @Autowired on fields — your unit tests become slow integration tests.

Gotcha 3: Singleton + mutable state
Singleton beans are shared across all requests. Storing request-specific state in a field on a singleton bean causes race conditions. Keep singletons stateless — use method parameters or request-scoped beans for per-request data.

LearningTree

Core — IoC, DI, Bean Lifecycle, AOP | Spring Guide