Explain Bean Lifecycle.

Hook: Interviewers ask this because Spring beans do not just “appear” — the container carefully builds, wires, initializes, and later destroys them.

Question: Explain Bean Lifecycle.

Answer: In Spring Boot, a bean’s lifecycle is the sequence of steps Spring follows from creating the object to destroying it. First Spring instantiates the bean, then fills in its dependencies, then runs initialization callbacks, and finally makes it ready for use. When the application shuts down, Spring calls destruction callbacks for beans it manages, especially singleton beans.

Interview-Ready Answer: In Spring Boot, the bean lifecycle is the full journey a bean takes inside the container. Spring creates the object, injects its dependencies, calls awareness and initialization callbacks like @PostConstruct or afterPropertiesSet(), and then hands the ready bean to the app. On shutdown, Spring calls destroy callbacks such as @PreDestroy for singleton beans, while prototype beans are created on demand and are not automatically destroyed by the container.

What actually happens under the hood

1. Spring loads bean definitions. A bean definition is the recipe for creating a bean: class, scope, dependencies, init and destroy callbacks, and so on. At this point nothing is instantiated yet.
2. Container customization runs first. Spring executes BeanFactoryPostProcessor implementations before objects are created. This lets the container modify bean definitions themselves, which is why this phase is earlier than normal bean initialization.
3. Bean post-processors are registered. A BeanPostProcessor is a hook that can intercept bean creation before and after initialization. Many Spring features use this idea, including annotation support and AOP, which is a proxy-based programming technique where Spring wraps a bean to add behavior like transactions.
4. Spring instantiates the bean. For a singleton bean, the default scope, Spring usually creates it eagerly during startup. For a prototype bean, Spring creates it only when you ask for it.
5. Dependencies are injected. Spring fills fields, setters, and constructor arguments. This is the core of IoC and DI: the container owns object creation and dependency wiring.
6. Aware callbacks run. If the bean implements interfaces like BeanNameAware or ApplicationContextAware, Spring passes useful container information to it. This is the bean learning about its own environment.
7. Before-initialization processors run. Spring calls postProcessBeforeInitialization() on each BeanPostProcessor. Annotation-driven callbacks like @PostConstruct are usually triggered here by a processor.
8. Initialization callbacks run. Common options are @PostConstruct, InitializingBean.afterPropertiesSet(), and a custom initMethod. Use these for lightweight setup, not slow remote calls.
9. After-initialization processors run. Spring calls postProcessAfterInitialization(). This is the last chance to wrap the bean, often with a proxy for transactions, security, or logging.
10. The bean is ready for use. Other beans now receive this fully initialized object.
11. Shutdown triggers destruction. When the context closes, Spring calls destruction callbacks for singleton beans: @PreDestroy, DisposableBean.destroy(), and a custom destroyMethod. This is the right place to close files, sockets, and connection pools.

Why this matters

Bean lifecycle answers are really about when Spring gives you a usable object and who owns cleanup. The key mental model is: Spring builds the object, injects it, prepares it, and later disposes of it if it owns the scope. If you remember that, you can reason about most startup bugs and shutdown bugs quickly.

Common lifecycle hooks and how they differ

Scope matters

Performance and practical notes

• Lifecycle work is O(number of beans) for startup and shutdown. If you have 200 singleton beans, each with a few callbacks, startup cost grows with that count.
• Most callback methods take microseconds, but if you open a database connection or call a remote API inside @PostConstruct, startup can jump from milliseconds to seconds.
• Spring’s default singleton scope is often eager, so a bad initialization can fail the whole application at startup instead of failing later in production.
• One subtle edge case: when AOP creates a proxy, the object other beans receive may be the proxy, not the raw class instance. The lifecycle callbacks still happen, but the final published object can be wrapped.
• Prototype beans are created by Spring, but their destruction is your responsibility. If a prototype opens a file or socket, you must close it yourself or use a higher-level resource manager.

Memory rule: “Construct, inject, initialize, proxy, serve, destroy.” That six-word chain is the lifecycle in interview form.

Real-world story: checkout service startup

Imagine a Spring Boot checkout service in an e-commerce system. It has a payment client, a fraud-check client, and a database repository. During startup, Spring creates those singleton beans, injects their dependencies, and runs initialization so the service is ready before it accepts traffic.

1. The payment client bean opens a pool of HTTP connections in its init phase.
2. The fraud client validates its API key and endpoint.
3. The repository bean gets a database connection factory injected, not an actual live connection.
4. When the app shuts down during deploy, Spring closes the HTTP pool and releases resources in destruction callbacks.

What goes wrong if you misunderstand lifecycle: a developer puts a slow remote metadata call into @PostConstruct. Startup time jumps from 8 seconds to 90 seconds, Kubernetes marks the pod unhealthy, and rollout fails. In logs you may see repeated readiness probe failures, delayed bean initialization messages, or a timeout while the app is still “starting.” Users feel it as a failed deploy or a brief outage, even though the code “works” locally.

Follow-up & Tricky Questions:

• What is the order of callbacks in a bean lifecycle? A good answer is: instantiate, inject dependencies, run aware callbacks, run BeanPostProcessor before-initialization hooks, then init callbacks, then after-initialization hooks, and finally destroy callbacks on shutdown.
• What is the difference between @PostConstruct and afterPropertiesSet()? Both run after dependency injection, but @PostConstruct is annotation-based and cleaner, while afterPropertiesSet() ties the class to Spring’s InitializingBean interface.
• How does Spring manage prototype bean destruction? It usually does not. Spring creates prototype beans, but the caller is responsible for cleanup, so you should avoid resource-heavy work in prototype scope unless you manage lifecycle manually.
• What is a BeanPostProcessor used for? It lets Spring intercept beans before and after initialization, which is how many framework features work, including proxy creation for AOP.
• What happens with lazy beans? Lazy singleton beans are not created at startup; Spring waits until the first time they are requested, which can improve startup time but move failures later.
• When does ApplicationContext call destroy methods? On context close or JVM shutdown if shutdown hooks are enabled, but only for beans managed in scopes where Spring owns destruction, mainly singletons.
• Gotcha: Does @PreDestroy run for prototype beans? Usually no. That is a common interview trap: Spring does not track prototype destruction the way it tracks singleton shutdown.
• Gotcha: Is constructor injection part of initialization? Not exactly. Construction happens first; dependency injection and init callbacks happen after the object exists.
• Gotcha: Can a bean be proxied after initialization? Yes. Spring may return a proxy from postProcessAfterInitialization(), so the final object seen by other beans is sometimes a wrapper around the original bean.

Common Mistakes:

• Mixing up construction and initialization. Correction: the constructor creates the object; initialization happens after Spring injects dependencies.
• Assuming every bean is destroyed automatically. Correction: singleton beans are destroyed on context close, but prototype beans are not.
• Doing heavy work in @PostConstruct. Correction: keep it lightweight; long remote calls can slow startup and break readiness probes.
• Thinking lifecycle hooks are only annotations. Correction: Spring also supports interfaces like InitializingBean, DisposableBean, and processor hooks like BeanPostProcessor.

Memory Hook: “Build it, wire it, bless it, use it, bury it.” Think of Spring as a stage manager: it builds the actor, hands them props, gives the cue, lets them perform, and cleans the stage afterward.

Cheat Sheet:

• Spring manages bean lifecycle inside the ApplicationContext.
• Flow: instantiate → inject → aware callbacks → before-init → init → after-init → use → destroy.
• @PostConstruct and afterPropertiesSet() are init hooks; @PreDestroy and destroy() are cleanup hooks.
• Singleton beans are destroyed automatically; prototype beans are not.
• BeanPostProcessor is the hook behind many Spring features, including proxies.
• Keep init and destroy logic fast and side-effect safe.

Practice Tasks:

• Change the example bean to @Lazy and observe that creation moves from startup to first access.
• Add a second prototype bean that opens a file, then write manual cleanup code to see why Spring does not destroy it for you.
• Replace the logging BeanPostProcessor with one that returns a proxy-like wrapper and notice how after-initialization can alter the final bean reference.