@Lazy Annotation — Deferred Bean Initialization

Spring's default behavior is eager initialization — all singleton beans are created at startup before the application handles any request. This is deliberate: configuration errors surface immediately instead of crashing on the first user request. @Lazy trades that safety for faster startup.

What it does

• The bean definition is still registered — Spring knows it exists
• Instead of creating the bean at startup, Spring injects a CGLIB proxy into dependents
• The real bean is created on the first method call through the proxy

The trade-off

• Faster startup — the expensive bean is not created until needed
• Deferred failure detection — a misconfigured @Lazy bean will not fail startup; it fails on the first request, a production failure instead of a deployment failure

Three placement levels give three different scopes

• @Lazy on a @Configuration class — every @Bean method inside becomes lazy by default
• @Lazy on a single @Bean method or class — only that bean is lazy
• @Lazy on an injection-point parameter — one consumer gets a proxy, other consumers still get the real bean eagerly; usually the right one

Global `spring.main.lazy-initialization=true`

• Flips the default for the whole application — every bean lazy unless annotated @Lazy(false)
• Useful for dev-loop restart speed (often 30–60% faster)
• Never enable in production — every configuration error now surfaces on first request instead of at boot

Interaction with `@PostConstruct`

• A @Lazy bean's @PostConstruct runs on first use, not at startup
• Side effects assumed to happen at boot (cache warmup, scheduler registration) are deferred
• The first request pays full init cost, inflating cold-start p99

The circular dependency trap

• The most common use of @Lazy in production is breaking circular dependencies — but it masks the design problem
• When someone removes the annotation during refactoring, the BeanCurrentlyInCreationException returns with no explanation
• Fix the design instead: extract the shared concern, use events, or apply interface segregation

Use @Lazy for genuinely expensive beans that are not always needed, at the injection-point parameter level for fine-grained control. Never use it as a permanent fix for circular dependencies, and never enable global lazy init in production.