BeanFactory vs ApplicationContext.

Hook: Interviewers love this question because it checks whether you know Spring’s core container or just the surface-level annotations.

Question: BeanFactory vs ApplicationContext.

Answer: BeanFactory is Spring’s basic IoC container: it stores bean definitions, creates beans, and hands them out with getBean(). ApplicationContext builds on top of it and adds richer features such as event publishing, message resolution, resource loading, and environment access. In Spring Boot, you usually work with ApplicationContext because it gives you the full application lifecycle and the extra services most real apps need.

Interview-Ready Answer: "I think of BeanFactory as the engine that knows how to create and wire beans, while ApplicationContext is the full container around it. ApplicationContext extends BeanFactory, so it can do everything BeanFactory can, but it also adds things like events, internationalization, resource loading, and the normal Spring Boot startup lifecycle. In practice, Spring Boot uses ApplicationContext by default because it eagerly creates non-lazy singleton beans at refresh time and gives you a much richer programming model."

Detailed Explanation: The easiest way to remember this is: BeanFactory is the core container, and ApplicationContext is the enterprise-friendly wrapper around it. Both know how to create beans and resolve dependencies, but only the context gives you the wider application services that make Spring Boot feel powerful instead of just usable.

What each one is

Aspect	BeanFactory	ApplicationContext
Role	Core container	Full container
Bean creation	On demand	Non-lazy singletons on refresh
Extra services	Beans only	Events, i18n, resources, env
Typical use	Framework internals	Spring apps, Boot
Footprint	Smaller	Richer startup

How it works under the hood

1. Spring Boot creates a concrete ApplicationContext implementation, such as AnnotationConfigServletWebServerApplicationContext for web apps or AnnotationConfigApplicationContext for non-web apps. This is a ConfigurableApplicationContext, which means it can be refreshed and closed.
2. Spring loads bean definitions first. A bean definition is just metadata that says what class to create, how to wire it, and whether it is lazy, singleton, or prototype.
3. Spring runs BeanFactory post-processors. A post-processor is a callback that can change bean definitions before objects are created, which is how a lot of auto-configuration and annotation processing works.
4. Spring then registers BeanPostProcessors. A BeanPostProcessor is a hook that runs before and after bean initialization; it is often used for proxies, validation, and framework magic.
5. The context pre-instantiates all non-lazy singleton beans. By default, singleton scope means one shared object per container, and @Lazy means Spring waits until the bean is actually requested.
6. After refresh, the context publishes startup events. That is why @EventListener works naturally in an ApplicationContext, while plain BeanFactory does not offer that API.

When to use which

• Use ApplicationContext for almost all Spring Boot applications. It gives you the full lifecycle, auto-configuration, events, property resolution, resource loading, and message bundles.
• Use BeanFactory when you are writing framework code, a very small embedded container, or a custom setup where you want the bare minimum.
• Think of Spring Boot defaults as context-first. Boot is designed around a rich application container, not a stripped-down bean registry.

Performance and edge cases

Bean lookup is usually very fast because Spring keeps bean metadata in maps, so the average lookup feels like O(1). Type-based lookup can do more work because Spring may need to filter candidates, resolve aliases, and choose a primary bean. The real cost is usually not lookup; it is bean construction, proxy creation, database startup, and initialization callbacks.

A common interview detail: ApplicationContext is not “eager for everything.” It eagerly creates non-lazy singleton beans at refresh time, but @Lazy beans and prototype beans are still created on demand. So the right mental model is “context does a startup pass,” not “context creates every object immediately.”

For numbers: in a typical Boot service with 100-300 beans, bean lookup itself is usually microseconds to low milliseconds, while startup time is dominated by heavyweight beans such as JPA, Flyway, HTTP clients, or connection pools. If a bean opens a DB connection or warms a cache, that one bean can cost far more than the container lookup around it.

One-line summary

BeanFactory is the minimal bean engine. ApplicationContext is the full-featured app container built on top of that engine.

Real-World Story: Imagine a checkout service in an e-commerce system. At startup, it needs to preload exchange rates, connect to Redis, and listen for a custom warmup event before serving traffic. That is a natural fit for ApplicationContext, because it can publish and consume events and run the normal startup lifecycle.

Now imagine a developer thinks, “BeanFactory is lighter, so let’s use that everywhere.” The warmup listener never fires, the cache is not preloaded, and the first customer request has to create expensive objects on the fly. In logs you might see missing event messages, slow first-request latency, or even NoSuchBeanDefinitionException if the code was relying on context-managed wiring that was not set up correctly.

The user-visible symptom is brutal: the app looks healthy after deploy, but the first few checkouts are slow or fail. A p95 latency that should be around 120 ms suddenly jumps to several seconds because the expensive setup moved from startup time into the middle of a live request. That is exactly why Spring Boot prefers a rich ApplicationContext instead of a bare-bones bean factory.

Follow-up & Tricky Questions:

• Is ApplicationContext a BeanFactory? Yes. It extends the bean-factory hierarchy, so every context can do bean lookup and dependency wiring; it just adds richer services on top.
• Why does Spring Boot use ApplicationContext by default? Because Boot is meant for real applications, and apps need events, environment properties, resource loading, and startup lifecycle hooks, not just bean creation.
• Does BeanFactory support dependency injection? Yes. DI is part of the core container, so BeanFactory can create and wire beans; it is just the minimal API.
• What is ConfigurableApplicationContext? It is the mutable, lifecycle-aware form of ApplicationContext that can be refreshed and closed. Boot uses this kind of context during startup.
• Does ApplicationContext create every bean eagerly? No. It eagerly creates non-lazy singletons, but lazy beans and prototype beans are still created only when requested.
• Tricky: If I inject BeanFactory, do I lose ApplicationContext features? Not necessarily. You are only holding a lower-level API view; if the actual object is an ApplicationContext, the richer features still exist on the container itself.
• Tricky: Is ApplicationContext always slower? Startup can be heavier because it does more work up front, but runtime bean access is usually similar. The extra cost is mostly during refresh, not every lookup.
• Tricky: Is BeanFactory obsolete? No. It is the foundation of Spring’s container model and still matters in framework internals and custom embedding scenarios.

Common Mistakes:

• Mistake: Saying BeanFactory cannot do dependency injection. Correction: It is the core DI container; ApplicationContext only adds more services.
• Mistake: Saying ApplicationContext creates every bean at startup. Correction: Only non-lazy singletons are pre-instantiated; lazy and prototype beans are not.
• Mistake: Treating BeanFactory as obsolete. Correction: It is the foundation under the richer context and still matters for internals.
• Mistake: Forgetting the extra features. Correction: ApplicationContext adds events, i18n, resources, and environment access, which are exactly why Boot uses it.

Memory Hook: BeanFactory = kitchen stove. It cooks the beans. ApplicationContext = full restaurant. It cooks, announces orders, translates the menu, and handles the whole dining experience.

Cheat Sheet:

• BeanFactory is the minimal Spring IoC container.
• ApplicationContext extends it and adds app-level services.
• Spring Boot uses ApplicationContext by default.
• BeanFactory creates beans on demand; ApplicationContext pre-instantiates non-lazy singletons on refresh.
• Lookup is fast in both; startup work is usually where the difference shows up.
• If you need events, resources, i18n, or environment access, choose ApplicationContext.

Practice Tasks:

• Create a @Lazy bean and print a line in its constructor. Confirm it is created only when first requested.
• Add an @EventListener method and publish a custom event from a CommandLineRunner.
• Write a tiny test with AnnotationConfigApplicationContext and compare what you can do there versus a plain DefaultListableBeanFactory.