Spring Core Interview Questions

IoC means your classes do not create or look up their own dependencies; a container does it for them. In Spring the ApplicationContext creates objects (beans), wires them together and manages their lifecycle. Control over object creation is "inverted" from your code to the framework.

DI is the way IoC is implemented: dependencies are passed in instead of created with new.

• Fields can be final, so the object is immutable and never half-built.
• Dependencies are visible in the constructor; too many parameters signals a class doing too much.
• Unit tests can call new OrderService(mockRepo) without Spring or reflection.
• Circular dependencies fail fast at startup instead of hiding.

@Service
public class OrderService {
    private final OrderRepository orderRepository;
    private final PaymentClient paymentClient;

    // single constructor: @Autowired is optional
    public OrderService(OrderRepository orderRepository, PaymentClient paymentClient) {
        this.orderRepository = orderRepository;
        this.paymentClient = paymentClient;
    }
}

Spring Boot always uses an ApplicationContext (e.g. AnnotationConfigServletWebServerApplicationContext).

All four are stereotypes that mark a class for component scanning; @Service, @Repository and @Controller are meta-annotated with @Component.

@Component goes on your own class and is picked up by component scanning. @Bean goes on a method inside a @Configuration class and is used for classes you cannot annotate (third-party: RestClient, ObjectMapper, PasswordEncoder) or when creation needs logic.

@Configuration
public class AppConfig {
    @Bean
    public PasswordEncoder passwordEncoder() {
        return new BCryptPasswordEncoder();
    }
}

The prototype is injected once, when the singleton is created, so the singleton keeps using the same instance. To get a fresh one each time, inject ObjectProvider<T> and call getObject(), use a @Lookup method, or a scoped proxy (proxyMode = ScopedProxyMode.TARGET_CLASS).

instantiate (constructor)
  -> inject dependencies
  -> Aware callbacks (BeanNameAware, ApplicationContextAware)
  -> BeanPostProcessor.postProcessBeforeInitialization
  -> @PostConstruct  -> InitializingBean.afterPropertiesSet -> init-method
  -> BeanPostProcessor.postProcessAfterInitialization  (AOP proxies are created here)
  -> bean is ready
  ... context closes ...
  -> @PreDestroy -> DisposableBean.destroy -> destroy-method

@PostConstruct/@PreDestroy come from jakarta.annotation in Spring Boot 3.

Two beans implement the same type (e.g. RazorpayGateway and StripeGateway implement PaymentGateway). Fix it with @Primary on the default one, or @Qualifier("razorpayGateway") at the injection point. You can also inject List<PaymentGateway> or Map<String, PaymentGateway> to get all of them.

Bean A needs B and B needs A. With constructor injection Spring cannot create either and fails with BeanCurrentlyInCreationException; Spring Boot 2.6+ forbids circular references by default even for field injection. The real fix is a redesign: extract the shared logic into a third bean, or use events. A quick workaround is @Lazy on one constructor parameter.