@Lazy Bean Initialization in Spring

Direct Answer

@Lazy on a bean definition requests deferred initialization until the bean is needed. @Lazy on an injection point can inject a lazy-resolution proxy. Non-lazy singleton beans are normally pre-instantiated when an ApplicationContext refreshes, while prototypes and other scopes already follow their own creation rules. @Lazy can break one construction-time cycle, but that often hides a design problem and moves failures to first use.

Code Example

@Component
@Lazy // not created at startup; built on first use
class ReportEngine {
    ReportEngine() { System.out.println("Heavy init..."); }
}

@Service
class ReportService {
    private final ObjectProvider<ReportEngine> engine;

    ReportService(ObjectProvider<ReportEngine> engine) {
        this.engine = engine; // ReportEngine still not built here
    }

    void run() {
        engine.getObject().generate(); // built now, on first call
    }
}

Common Mistakes & Pitfalls

• Lazy everywhere to fix slow startup: Freshers see a 15-second startup and annotate every bean with @Lazy. This masks the real problem (inefficient initialization logic) and moves errors to runtime. Fix the root cause instead—optimize database queries in @PostConstruct, remove unnecessary eager loading, or split heavyweight beans into separate modules.
• Not understanding proxy behavior: When you inject a @Lazy bean, Spring injects a proxy, not the real object. The first method call on that proxy triggers bean creation. Freshers sometimes serialize or reflect on the proxy and get confused by CGLIB classes in stack traces.
• Using @Lazy to break circular dependencies without fixing the design: Circular dependencies indicate poor design—two beans shouldn't depend on each other. @Lazy papers over the symptom but doesn't fix the coupling. Refactor one bean to use an event or callback instead of direct dependency.