Spring’s Inversion of Control (IoC) mechanism shifts object instantiation, dependency resolution, and lifecycle management from application code to a centralized container. The architecture relies heavily on metadata parsing, Java reflection, and a series of lifecycle callbacks.

Core Container Abstractions

The framework exposes two primary interfaces for managing components:

• BeanFactory: The foundational contract providing basic IoC capabilities. It operates on a lazy-initialization model, instantiating components only when explicitly requested via getBean(). It lacks enterprise features like event propagation or resource abstraction.
• ApplicationContext: An advanced superset of BeanFactory designed for production environments. It defaults to eager initialization for singletons, integrates message resolution, application event publishing, and resource loading. Common implementations include AnnotationConfigApplicationContext and ClassPathXmlApplicationContext.

Container Bootstrap Pipeline

When an application context starts, it executes a deterministic sequence to prepare the runtime environment:

1. Metadata Ingestion: The container scans configuration classes or XML files, identifying candidate components marked with stereotypes like @Component or @Configuration.
2. BeanDefinition Generation: Each discovered class is transformed into a BeanDefinition object. This metadata blueprint captures the class type, scope, constructor arguments, property values, and lifecycle callbacks.
3. Registry Population: These definitions are stored in a BeanDefinitionRegistry, internally backed by a concurrent map structure keyed by component identifiers.
4. Instantiation & Wiring: The container iterates through the registry, materializing objects via reflection, resolving cross-references, and executing initialization routines.
5. Singleton Caching: Fully initialized singletons are placed into a primary cache (singletonObjects), enabling rapid subsequent retrieval without re-instantiation.

Underlying Technical Foundations

The container’s behavior is powered by specific Java capabilities and architectural patterns:

• Reflection API: Dynamic class loading, constructor invocation, and field/method accessibility overrides enable the container to instantiate and wire objects without compile-time coupling.
• Factory Pattern: Abstracts the instantiation logic, allowing the container to produce objects based on metadata rather then hardcoded new operators.
• Singleton Registry: Maintains a thread-safe cache to guarantee single-instance semantics across the application context.
• Observer Pattern: Drives the event publishing mechanism, allowing decoupled components to react to container state changes (e.g., ContextRefreshedEvent).

Bean Lifecycle Execution Order

A managed component traverses a strict sequence from creation to destruction:

1. Object Materialization: Constructor execution via reflection.
2. Dependency Population: Injection of collaborators through fields, setters, or constructors.
3. Aware Interface Callbacks: If the component implements BeanNameAware, ApplicationContextAware, or similar contracts, the container injects contextual references.
4. Pre-Initialization Interception: BeanPostProcessor impllementations execute their postProcessBeforeInitialization logic.
5. Initialization Routines: Execution of @PostConstruct methods, InitializingBean.afterPropertiesSet(), or custom init-method configurations.
6. Post-Initialization Interception: BeanPostProcessor implementations run postProcessAfterInitialization. This stage typically generates AOP proxies.
7. Active State: The component resides in the singleton pool, ready for application use.
8. Destruction Phase: Upon context shutdown, @PreDestroy methods, DisposableBean.destroy(), or custom destroy-method configurations are invoked.

Lifecycle Verification Example

The following implementation demonstrates the execution order using modern Spring annotations and lifecycle interfaces.

@Component
public class NotificationEngine implements InitializingBean, BeanNameAware {

    private final MessageBroker broker;
    private String componentId;

    // Constructor injection
    public NotificationEngine(MessageBroker broker) {
        this.broker = broker;
        System.out.println("[1] Constructor executed");
    }

    @Override
    public void setBeanName(String name) {
        this.componentId = name;
        System.out.println("[2] Aware callback: " + name);
    }

    @PostConstruct
    public void setupResources() {
        System.out.println("[3] @PostConstruct triggered");
    }

    @Override
    public void afterPropertiesSet() {
        System.out.println("[4] InitializingBean callback");
    }

    public void customInit() {
        System.out.println("[5] Custom init-method executed");
    }

    @PreDestroy
    public void releaseResources() {
        System.out.println("[7] @PreDestroy triggered");
    }
}

@Component
public class LifecycleInterceptor implements BeanPostProcessor {

    @Override
    public Object postProcessBeforeInitialization(Object bean, String beanName) {
        if (bean instanceof NotificationEngine) {
            System.out.println("[BPP-Before] Interception phase");
        }
        return bean;
    }

    @Override
    public Object postProcessAfterInitialization(Object bean, String beanName) {
        if (bean instanceof NotificationEngine) {
            System.out.println("[BPP-After] Proxy wrapping phase");
        }
        return bean;
    }
}

public class ApplicationBootstrap {
    public static void main(String[] args) {
        AnnotationConfigApplicationContext ctx = 
            new AnnotationConfigApplicationContext("com.system.core");
        
        ctx.getBean(NotificationEngine.class);
        ctx.close();
    }
}

Console Output Sequence:

[1] Constructor executed
[2] Aware callback: notificationEngine
[BPP-Before] Interception phase
[3] @PostConstruct triggered
[4] InitializingBean callback
[5] Custom init-method executed
[BPP-After] Proxy wrapping phase
[7] @PreDestroy triggered

Framework Extension Hooks

Spring exposes several interception points for advanced container manipulation:

• BeanDefinitionRegistryPostProcessor: Allows programmatic registration or modification of component metadata before instantiation begins.
• BeanFactoryPostProcessor: Executes after metadata loading but before object creation, enabling property overrides or scope adjustments.
• BeanPostProcessor: Provides pre- and post-initialization hooks, serving as the foundation for annotation processing and AOP proxy generation.
• FactoryBean: Acts as a specialized factory for complex object creation, abstracting intricate instantiation logic (e.g., ORM session factories or RPC clients) behind a standard container interface.