Spring Core & Dependency Injection

Spring bean scope controls how many instances of a bean definition exist, and how long each one lives:

• singleton (the default): exactly one instance per Spring container, shared by every injection point. This fits stateless components — most @Service/@Repository beans, since they hold no per-request mutable state.

@Service // singleton by default
class OrderService { }

• prototype: a new instance is created every time the bean is requested, whether injected or fetched via getBean(). This fits objects that hold mutable, non-thread-safe per-use state.

@Component
@Scope("prototype")
class ReportBuilder { /* accumulates mutable state per report */ }

• request (web-aware): one instance per HTTP request — useful for holding request-scoped data cleanly instead of threading it through method parameters.
• session (web-aware): one instance per HTTP session — useful for per-user state like a shopping cart.
• application (web-aware): one instance per ServletContext — similar to singleton, but scoped to the web application rather than the Spring container specifically. This matters when multiple contexts share a servlet context.

A common gotcha: injecting a prototype-scoped bean into a singleton-scoped bean via normal field/constructor injection only resolves it once, at the singleton's creation time. Every subsequent use gets the same prototype instance, defeating the purpose. Fixing this needs a scoped proxy (proxyMode = ScopedProxyMode.TARGET_CLASS), or looking the bean up via ObjectFactory/ObjectProvider each time it's actually needed, so a fresh prototype instance is fetched per use.

Rule of thumb: default to singleton. Reach for prototype (or a web-aware scope) only when a bean genuinely needs per-use or per-request/session mutable state.

For a singleton bean, the full lifecycle (simplified) runs in this order:

1. Instantiation — Spring calls the bean's constructor, resolving constructor-injected dependencies at this point.
2. Dependency injection — setter and field injection (@Autowired on setters/fields) happens after construction.
3. Aware interface callbacks — if the bean implements marker interfaces like BeanNameAware, BeanFactoryAware, or ApplicationContextAware, Spring calls their respective setter methods. This gives the bean access to its own name, the factory, or the full context.
4. BeanPostProcessor.postProcessBeforeInitialization() — runs for every bean, for every registered BeanPostProcessor. This is a Spring extension point most application code never implements directly, but many Spring features are built on it internally.
5. Initialization callbacks, in this order:
   • @PostConstruct-annotated method (JSR-250, the most common modern choice).
   • InitializingBean.afterPropertiesSet() (if the bean implements that interface — an older, interface-based alternative).
   • A custom init-method specified via @Bean(initMethod = "...") or XML.
6. BeanPostProcessor.postProcessAfterInitialization() — this is where Spring applies AOP proxying. If the bean needs a proxy (for @Transactional, @Async, custom aspects, etc.), the proxy is created and returned here. That means the object other beans actually get injected may be a proxy wrapping the real instance.
7. Bean is ready — used by the application for its normal lifetime.
8. Destruction (on container shutdown), in a similar layered order: @PreDestroy, then DisposableBean.destroy(), then a custom destroy-method.

@Component
class CacheWarmer implements InitializingBean, DisposableBean {
    @PostConstruct
    void warmUp() { /* runs first among init callbacks */ }

    @Override
    public void afterPropertiesSet() { /* runs after @PostConstruct */ }

    @PreDestroy
    void logShutdown() { /* runs before destroy() */ }

    @Override
    public void destroy() { /* release resources */ }
}

Practical guidance: prefer @PostConstruct/@PreDestroy over implementing InitializingBean/DisposableBean directly. They're simple, annotation-based, and don't couple you to Spring-specific interfaces — unless you're writing framework-level code that specifically needs the interface-based contract.

Spring's default autowiring strategy resolves a dependency by type first. If more than one bean of that type exists, autowiring becomes ambiguous:

interface PaymentGateway { }
@Component class StripeGateway implements PaymentGateway { }
@Component class PayPalGateway implements PaymentGateway { }

@Service
class OrderService {
    @Autowired
    PaymentGateway gateway; // ambiguous! Two candidates — NoUniqueBeanDefinitionException at startup
}

@Primary designates one candidate as the default to use whenever multiple beans of a type match and no more specific instruction is given:

@Component
@Primary
class StripeGateway implements PaymentGateway { } // chosen by default among the candidates

@Qualifier lets a specific injection point name exactly which bean it wants, by bean name (or a custom qualifier value):

@Service
class OrderService {
    private final PaymentGateway gateway;

    OrderService(@Qualifier("payPalGateway") PaymentGateway gateway) {
        this.gateway = gateway; // explicitly requests the PayPal bean, regardless of @Primary
    }
}

Precedence: an explicit @Qualifier at the injection site always wins over @Primary. @Primary only matters when the injection point gives no more specific instruction. This lets you set a sensible application-wide default with @Primary, while still allowing specific call sites to opt into a different implementation via @Qualifier where needed.

@Qualifier can also be used as a meta-annotation on your own custom annotation, for more expressive, type-safe disambiguation than raw string bean names.

A circular dependency happens when Bean A depends on Bean B, and Bean B (directly or transitively) depends back on Bean A.

With setter/field injection, Spring can resolve this for singleton beans, using a mechanism internally called the "three-level cache" of early bean references. While constructing A, Spring notices A needs B. While constructing B, Spring notices B needs A. Instead of recursing infinitely, Spring exposes an early reference to the partially-constructed A — created but not yet fully populated/initialized — to satisfy B's dependency, then finishes populating both. This works because with setter/field injection, an object can exist before all its dependencies are actually set.

@Component
class A { @Autowired B b; }

@Component
class B { @Autowired A a; } // circular, but resolvable via setter/field injection

With constructor injection, this trick is impossible. A's constructor needs a fully-built B as an argument, and B's constructor needs a fully-built A. Neither object can exist yet to serve as an "early reference," since construction itself is blocked on the other. Spring detects this and fails fast at startup with BeanCurrentlyInCreationException, rather than silently falling back to some other injection style.

@Component
class A { A(B b) {} }   // constructor injection
@Component
class B { B(A a) {} }   // circular — fails at startup, cannot be resolved

Practical guidance: rather than switching back to setter injection just to "fix" a circular dependency, treat it as a design smell. It usually means two classes are too tightly coupled and should be refactored — for example, extracting shared logic into a third bean both depend on, or using @Lazy on one side as a genuinely last-resort workaround if a refactor isn't immediately feasible. Constructor injection surfacing this problem loudly at startup, instead of Spring quietly working around it, is generally considered a feature, not a limitation.

AOP (Aspect-Oriented Programming) lets you factor out cross-cutting concerns — logging, transaction management, security checks, caching — that would otherwise be scattered as repetitive boilerplate across many unrelated methods. Instead, you declare them once, separately, as an aspect:

@Aspect
@Component
class LoggingAspect {
    @Around("execution(* com.example.service.*.*(..))") // pointcut: which methods this applies to
    Object logExecutionTime(ProceedingJoinPoint pjp) throws Throwable {
        long start = System.currentTimeMillis();
        Object result = pjp.proceed(); // actually invoke the real method
        System.out.println(pjp.getSignature() + " took " + (System.currentTimeMillis() - start) + "ms");
        return result;
    }
}

Many familiar Spring annotations (@Transactional, @Async, @Cacheable, @PreAuthorize) are themselves built as aspects under the hood.

How it's implemented — proxies: Spring AOP (unlike full AspectJ compile-time/load-time weaving) works by wrapping the target bean in a runtime proxy. The proxy intercepts method calls, runs the relevant aspect logic, and then delegates to the real object:

• JDK dynamic proxy: used when the target bean implements at least one interface. Spring generates a proxy implementing that same interface at runtime, delegating calls through the aspect logic to the real implementation.
• CGLIB proxy: used when the target bean has no interface (or Spring is configured to always prefer class-based proxying). Spring generates a runtime subclass of the target class itself, overriding its public/protected methods to insert the aspect logic.

Why this matters practically — two classic gotchas:

1. Self-invocation bypasses the proxy: calling another @Transactional/aspect-advised method on this, from within the same class, calls the real method directly — never through the proxy. So the aspect (transaction, logging, etc.) simply doesn't apply. This is why calling one @Transactional method from another method in the same class famously doesn't get its own transaction.
2. final methods/classes can't be proxied by CGLIB — it needs to generate a subclass, which can't override final methods. Private methods can never be advised by either proxy style, since a proxy can only intercept calls that actually go through it externally.

Spring's ApplicationContext includes a built-in, in-process publish-subscribe event system, letting beans communicate without any direct reference to each other:

1. Define an event (often a simple POJO or a record):

record UserRegisteredEvent(String userId, String email) { }

2. Publish it, from anywhere holding an ApplicationEventPublisher:

@Service
class UserService {
    private final ApplicationEventPublisher publisher;
    UserService(ApplicationEventPublisher publisher) { this.publisher = publisher; }

    void register(User user) {
        // ... save the user ...
        publisher.publishEvent(new UserRegisteredEvent(user.getId(), user.getEmail()));
    }
}

3. Listen for it, in one or more independent beans:

@Component
class WelcomeEmailSender {
    @EventListener
    void onUserRegistered(UserRegisteredEvent event) {
        sendWelcomeEmail(event.email());
    }
}

@Component
class UserRegisteredAuditor {
    @EventListener
    void onUserRegistered(UserRegisteredEvent event) {
        auditLog.record("user registered: " + event.userId());
    }
}

UserService has no idea either listener exists. New behavior can be added later — say, a third listener granting a signup bonus — without touching UserService at all. That's the core decoupling benefit.

Practical notes:

• By default, listeners run synchronously, on the same thread as the publisher, as part of the same call. An exception in a listener propagates back to the publishing code unless handled. Adding @Async to a listener method makes it run on a separate thread instead (requires @EnableAsync).
• @TransactionalEventListener lets a listener run only after the publishing transaction successfully commits (or at other transaction-phase points). This helps avoid side effects — like sending an email — for a registration that ultimately got rolled back.
• Before @EventListener (Spring 4.2+), the older style required implementing ApplicationListener<UserRegisteredEvent> directly. It's functionally equivalent, just more verbose.

All three annotations trigger dependency injection, but come from different origins and resolve slightly differently:

• @Autowired (Spring's own annotation, org.springframework.beans.factory.annotation): resolves by type first. If multiple candidates match, it falls back to matching by the field/parameter name, or requires explicit disambiguation via @Qualifier/@Primary. Supports a required attribute (@Autowired(required = false)) to make a dependency optional.

@Autowired
private PaymentGateway gateway; // by type, Spring-specific

• @Resource (JSR-250, javax.annotation/jakarta.annotation — a Java EE/Jakarta EE standard, not Spring-specific): resolves by name first, matching the field/parameter name against a bean name, then falls back to by type if no name match is found.

@Resource(name = "stripeGateway")
private PaymentGateway gateway; // by name first — standard, not Spring-only

• @Inject (JSR-330, javax.inject/jakarta.inject — a broader dependency-injection standard also supported by other DI frameworks like Guice): behaves very similarly to @Autowired — by type, then qualifiers (@Named is JSR-330's equivalent of @Qualifier). It has no required attribute or other Spring-specific conveniences, and no equivalent to @Autowired's constructor-optional inference.

Practical guidance: @Autowired is by far the most common choice in Spring codebases, and integrates most smoothly with Spring-specific features (@Qualifier, @Primary, required = false). @Inject/@Resource matter mainly when writing code meant to be portable across DI frameworks, or in codebases with a standards-first convention. For the common case of a single unambiguous dependency, all three behave the same.