Spring Core, DI & Bean Lifecycle

The test compiles but every injected field is null, so the first call throws NullPointerException. Constructor injection makes dependencies explicit, lets fields be final, and makes the object impossible to create in an invalid state.

@Service
public class OrderService {
    private final PaymentClient payments;
    private final OrderRepository repo;

    public OrderService(PaymentClient payments, OrderRepository repo) {
        this.payments = payments;
        this.repo = repo;
    }
}

With a single constructor, @Autowired is optional (since Spring 4.3). In the test you pass mocks directly, with no Spring context.

Startup fails with BeanCurrentlyInCreationException wrapped in UnsatisfiedDependencyException. Since Spring Boot 2.6, spring.main.allow-circular-references defaults to false, so even setter/field cycles that used to work are rejected.

• Constructor cycles can never be resolved by the container, because neither object can be created before the other.
• The right fix is to redesign: extract the shared logic into a third bean, or invert one dependency with an event.
• Quick escapes: @Lazy on one constructor parameter (injects a proxy), or allow-circular-references=true (treat as technical debt).

NoUniqueBeanDefinitionException: expected single matching bean but found 2. Resolve with @Primary on the default one, or @Qualifier("reportingDs") at the injection point.

@Bean @Primary
DataSource mainDs() { ... }

@Bean
DataSource reportingDs() { ... }

public ReportRepo(@Qualifier("reportingDs") DataSource ds) { ... }

An explicit @Qualifier wins over @Primary. As a last fallback, Spring matches the parameter name to a bean name (needs -parameters, which Boot's Maven/Gradle plugins enable).

No. Injection happens once when the singleton is created, so it holds one prototype instance forever. To get a fresh instance per use, inject ObjectProvider<T> (or Provider<T>), use a scoped proxy, or a lookup method.

@Service
class ReportService {
    private final ObjectProvider<ReportBuilder> builders;
    ReportService(ObjectProvider<ReportBuilder> builders) { this.builders = builders; }
    Report build() { return builders.getObject().build(); }
}

@Scope(value = "prototype", proxyMode = ScopedProxyMode.TARGET_CLASS) also works, but every method call on the proxy creates a new instance, which is rarely what you want for a stateful builder.

Declare the bean @RequestScope (which sets proxyMode = TARGET_CLASS) and inject it normally. The singleton receives a CGLIB proxy that resolves the real instance from the current request on each call.

• Without the proxy you get ScopeNotActiveException: No scope registered for scope name 'request' at startup, because no request exists when the singleton is created.
• Calls outside a web request thread (e.g., @Async or scheduled jobs) fail with the same exception, since the RequestContextHolder is thread-bound.
• Class must be non-final with a usable constructor for CGLIB proxying.

Init: @PostConstruct (via CommonAnnotationBeanPostProcessor), then afterPropertiesSet(), then custom initMethod. Destroy: @PreDestroy, then DisposableBean.destroy(), then custom destroyMethod.

• Full sequence: constructor, dependency injection, *Aware callbacks, postProcessBeforeInitialization, init callbacks, postProcessAfterInitialization (where AOP proxies are typically created).
• @Bean methods infer a public close()/shutdown() as destroy method automatically; set destroyMethod = "" to disable.
• javax.annotation became jakarta.annotation in Boot 3.

During @PostConstruct the bean is not fully initialized or proxied yet, and other beans' infrastructure (transaction advisors) may not be ready. Do startup data work in an ApplicationReadyEvent listener or ApplicationRunner, where the context is fully refreshed and proxies are in place.

@Component
class Seeder {
    @EventListener(ApplicationReadyEvent.class)
    @Transactional
    void seed() { ... }
}

Calling another bean's @Transactional method from @PostConstruct usually works because that bean is already a proxy, but calling your own @Transactional method does not, since this is the raw target.

A BeanPostProcessor intercepts every bean before and after initialization, which is how @Autowired, @PostConstruct, @Async, and AOP proxies are applied. BPPs are instantiated early, before regular beans, so any bean they depend on is created before all BPPs are registered and misses processing.

• Log: Bean 'x' of type [...] is not eligible for getting processed by all BeanPostProcessors.
• Consequence: that bean may silently lack @Transactional, @Async or security proxies.
• Fixes: declare BPP @Bean methods static, inject dependencies lazily (ObjectProvider), and keep BPPs free of business dependencies.

The inner annotation is ignored. Spring AOP is proxy-based, and a call through this bypasses the proxy, so no advice runs and both methods share the caller's transaction.

Fixes, in order of preference:

• Move the inner method to another bean.
• Self-inject the proxy (@Lazy self reference) or use AopContext.currentProxy() with exposeProxy = true.
• Use AspectJ weaving (@EnableTransactionManagement(mode = ASPECTJ)), which also handles private methods.

Boot defaults to CGLIB proxies (spring.aop.proxy-target-class=true), which subclass the bean. A final class cannot be subclassed, and final methods cannot be overridden so their advice is skipped silently.

• JDK dynamic proxies need an interface and only proxy interface methods; injecting by concrete class then fails with BeanNotOfRequiredTypeException.
• Kotlin classes are final by default; use the kotlin-spring (allopen) plugin.
• CGLIB proxies are created via Objenesis, so the constructor is not re-run on the proxy; avoid logic in constructors that depends on the proxy being initialized.

On a bean definition, @Lazy defers creation until first use. On an injection point, Spring injects a lazy-resolving proxy, so the target is created on first method call.

• Benefit: faster startup, and a way to break constructor cycles.
• Cost: configuration errors surface at runtime on first request instead of at startup; the first call pays the init latency.
• spring.main.lazy-initialization=true makes everything lazy, which can hide misconfiguration and slows the first requests; pair with explicit eager exceptions (@Lazy(false)).

Use @ConditionalOnProperty, @ConditionalOnClass, and @ConditionalOnMissingBean respectively.

@Bean
@ConditionalOnProperty(name = "feature.audit.enabled", havingValue = "true")
AuditService auditService() { return new AuditService(); }

@Bean
@ConditionalOnMissingBean
Clock clock() { return Clock.systemUTC(); }

• @ConditionalOnMissingBean is evaluated at the time the condition is processed, so it is reliable only in auto-configuration classes (processed last), not in ordinary user @Configuration.
• havingValue defaults to "any value except false"; matchIfMissing=true makes the feature default-on.

The profile is not active. Activate with spring.profiles.active=prod, SPRING_PROFILES_ACTIVE, @ActiveProfiles("prod") in tests, or programmatically via SpringApplication.setAdditionalProfiles.

• If no profile is active, @Profile("default") beans are used; !prod negation and expressions like @Profile("prod & eu") are supported.
• spring.profiles.include adds profiles; spring.profiles.group.prod=db,metrics groups them (Boot 2.4+).
• spring.profiles.active cannot be set inside a profile-specific file or spring.config.activate.on-profile document.

Inject all implementations as a Map<String, PaymentGateway> (bean name to bean) or List<PaymentGateway> with a supports(tenant) method, and choose at runtime. Static qualifiers decide at startup, not per request.

@Service
class PaymentRouter {
    private final Map<String, PaymentGateway> gateways;
    PaymentRouter(Map<String, PaymentGateway> gateways) { this.gateways = gateways; }
    PaymentGateway forTenant(String t) { return gateways.getOrDefault(t, gateways.get("stripe")); }
}

@Component classes are scanned and instantiated as-is ("lite mode" for their @Bean methods). @Configuration classes are CGLIB-subclassed (full mode) so that calling one @Bean method from another returns the container singleton instead of a new object.

@Configuration
class Cfg {
    @Bean A a() { return new A(b()); } // b() returns the singleton bean
    @Bean B b() { return new B(); }
}

With @Configuration(proxyBeanMethods = false) (or @Component), b() creates a fresh B each call, bypassing the container. Prefer parameter injection (A a(B b)) and proxyBeanMethods=false, which is faster and required for native image friendliness.

Only container-created beans receive injection. An object created with new is invisible to the container, so its @Autowired fields are never populated.

• Make the class a bean and inject it, or create instances via ObjectProvider/a factory bean.
• For domain objects that must be created manually but need services, pass the dependency as a method argument, or use @Configurable with AspectJ (rare).
• Static fields and static methods cannot be injected directly.

Most often the class sits outside the package tree of the @SpringBootApplication class, so component scan never sees it.

Check in order:

• Package location versus the main class (or add scanBasePackages).
• Missing stereotype annotation, or the bean is excluded by @Profile/@Conditional.
• Interface injected but the implementation is an inner class or not annotated.
• A @Configuration imported with @Import is missing, or test slice (@WebMvcTest) does not load services (use @MockBean/@Import).
• Run with --debug or logging.level.org.springframework.beans=DEBUG to inspect the conditions report and definitions.

Use @Order(n) (lower value = higher priority) or implement Ordered. Without either, order is not guaranteed and depends on registration.

• @Order affects collection injection and ordered infrastructure (filters, advisors, @ControllerAdvice); it does not affect which bean is selected for a single-valued injection point; that is @Primary's job.
• @Priority (JSR-250) is honoured for single-injection tie-breaks in some paths, but @Order is conventional.

The property is absent. Provide a default with @Value("${timeout:30}"), or fix the property source. For groups of related properties prefer a typed @ConfigurationProperties class with validation.

• @Value supports SpEL (#{...}) but does no relaxed binding, so ${my.Timeout} must match the key more strictly.
• @ConfigurationProperties gives relaxed binding, type conversion (Duration, DataSize), metadata for IDE completion, and @Validated fail-fast.
• @Value in a BeanFactoryPostProcessor or a static context can resolve too early.

Beans are singletons by default and shared by all request threads, so mutable instance fields are a race condition and a data leak. Keep singletons stateless; pass state as parameters or use request-scoped/ThreadLocal-based holders with cleanup.

• Controllers, services and repositories should hold only final collaborators.
• If a cache field is needed, use ConcurrentHashMap or Spring Cache.
• Switching to prototype scope on a controller is a smell and does not fix state shared with singletons it calls.

Use @PreDestroy, DisposableBean, or SmartLifecycle for ordered start/stop with a phase. Beans are destroyed in reverse dependency order, so a bean's dependencies are still alive in its @PreDestroy.

• SmartLifecycle stop runs before plain bean destruction and lets you control order via getPhase() (higher phase starts last and stops first).
• @PreDestroy is not called when the JVM is killed with kill -9 or crashes; only on graceful close (shutdown hook registered by Boot).
• Prototype beans are never destroyed by the container.

An optional injection turns a missing bean into null/Optional.empty() instead of failing fast, so a misconfigured profile or condition silently disables a feature (for example, no audit or no cache).

• Use optional injection only for truly optional collaborators and log when absent.
• Prefer ObjectProvider<T>#ifAvailable with an explicit fallback, or a no-op implementation bean registered via @ConditionalOnMissingBean.
• Add a startup assertion or a health indicator for critical integrations.

Three options: a BeanPostProcessor that wraps the instance, a Spring AOP @Aspect with a pointcut on the type, or a decorator @Bean marked @Primary that holds the original (injected by @Qualifier).

@Bean @Primary
PaymentClient loggingClient(@Qualifier("rawClient") PaymentClient delegate) {
    return req -> { log.info("call {}", req); return delegate.send(req); };
}

AOP is least invasive but constrained by proxy rules (final classes, self-invocation). The explicit decorator is easiest to debug and test.

Spring caches the ApplicationContext keyed by configuration (classes, profiles, properties, mock/spy bean definitions, etc). Each distinct @MockBean set or @TestPropertySource creates a new cache key, so a new context is built.

• Consolidate mocks in a shared abstract base class or a @TestConfiguration using @Bean stubs.
• In Boot 3.4+, @MockitoBean (Spring Framework 6.2) replaces @MockBean, which is deprecated; the caching rule is the same.
• Avoid @DirtiesContext unless a test truly mutates the context.

BeanFactory is the basic container (lazy by default, DI only). ApplicationContext adds eager singleton creation, events, i18n, resource loading, environment/profile support, and automatic BPP registration.

• You almost never use a bare BeanFactory; the difference matters mostly when explaining why @Autowired or @PostConstruct works only in a context.
• ApplicationContext singletons are created eagerly at refresh, which surfaces wiring errors at startup.

@EventListener methods are registered by EventListenerMethodProcessor after all singletons are instantiated (afterSingletonsInstantiated). Events published during bean creation (including @PostConstruct) happen before listeners are registered, so they are lost.

• Publish after startup using ApplicationReadyEvent, SmartInitializingSingleton, or ContextRefreshedEvent.
• Listeners are synchronous and run in the publisher's thread/transaction by default; add @Async or use @TransactionalEventListener for after-commit semantics.
• ApplicationEvent subclassing is not required since Spring 4.2; any object works.