Top 60 Spring Interview Questions (2026)

Spring is an open-source Java framework whose core job is managing the objects your application depends on. Instead of your classes creating and connecting their own collaborators, a Spring container does it and injects them, which keeps components loosely coupled.

Teams use it because that wiring, plus built-in support for transactions, data access, web MVC, and security, removes a lot of boilerplate and makes code easier to test. Spring Boot builds on it to remove most configuration too.

Inversion of control means your objects don't create their own dependencies; something external (the Spring container) creates them and hands them over. Control of construction is inverted from your code to the framework.

Dependency injection is the specific way Spring does IoC: it injects the needed objects through a constructor, setter, or field. IoC is the principle; DI is the technique.

Constructor injection passes dependencies through the constructor; setter injection sets them via setter methods after construction; field injection puts them directly on fields with @Autowired.

The Spring team recommends constructor injection for required dependencies because it makes them explicit and mandatory, allows final fields, and lets you build the object in a test without the container. Setter injection suits optional dependencies. Field injection is discouraged because it hides dependencies and needs reflection to test.

A bean is any object that the Spring IoC container creates, configures, and manages. If the container owns its lifecycle, it's a bean; a plain object you new up yourself is not.

You tell Spring about beans through stereotype annotations (@Component and friends) picked up by component scanning, or through @Bean methods in a @Configuration class.

BeanFactory is the basic container that instantiates and wires beans lazily. ApplicationContext is a superset that adds event publishing, internationalization message sources, resource loading, and eager instantiation of singletons at startup.

In practice you almost always use ApplicationContext; BeanFactory shows up mainly in memory-constrained or embedded scenarios. Naming ApplicationContext as the everyday container is the expected answer.

A scope controls how many instances of a bean the container creates and how long they live. singleton (the default) means one shared instance per container; prototype means a new instance on every request for the bean.

In web applications there are also request, session, and application scopes, tied to the HTTP request, user session, and servlet context. Singleton beans must be stateless because they're shared across all callers.

A singleton bean is created once and the same instance is returned every time it's injected or looked up. A prototype bean is created fresh on each request, so every injection point gets its own instance.

Singletons hold no per-call state; prototypes are for stateful, short-lived objects. Also worth knowing: Spring fully manages the singleton lifecycle including destruction, but for prototypes it stops after handing the object over.

@Autowired tells Spring to inject a matching bean at that point: a constructor, setter, or field. By default it resolves by type, and if exactly one matching bean exists, Spring wires it in.

If no matching bean is found it fails at startup, unless you mark the injection optional with required=false, Optional, or @Nullable. On a class with a single constructor, @Autowired is now implied and can be omitted.

When two beans satisfy the same type, @Autowired can't pick one and startup fails. You disambiguate with @Qualifier("beanName") at the injection point, or mark one bean @Primary so it wins by default.

@Primary sets the fallback choice for the whole context; @Qualifier makes the choice at a specific injection point. Use @Primary for the common default and @Qualifier for the exceptions.

All four register a class as a Spring bean via component scanning. @Component is the generic stereotype; @Service, @Repository, and @Controller are specializations that carry the same behavior plus semantic meaning about the layer.

Two carry extra behavior: @Repository adds automatic translation of persistence exceptions into Spring's DataAccessException hierarchy, and @Controller marks a web MVC handler. Using the specific stereotype makes the architecture readable at a glance.

@Configuration marks a class as a source of bean definitions. Inside it, methods annotated @Bean return objects that Spring registers and manages as beans, using the method name as the bean name by default.

This is the Java-based alternative to XML configuration and to component scanning. You reach for @Bean when you need to construct a bean with custom logic or wire a third-party class you can't annotate.

Spring Framework is the core: the container, dependency injection, AOP, transactions, and the web stack. Spring Boot sits on top and removes configuration through auto-configuration, starter dependencies, and an embedded server, so you can run a standalone app with almost no setup.

Boot doesn't replace the framework; it opinionatedly configures it. A Boot app is still a Spring app underneath. Explaining that layering is exactly what this question checks.

Three styles: XML configuration (the original, now rare), annotation-based configuration with component scanning and stereotypes, and Java-based configuration with @Configuration and @Bean classes.

Modern apps use annotations plus Java config, and Spring Boot pushes almost everything into auto-configuration and properties files. XML shows up mainly in older codebases.

A single front controller, the DispatcherServlet, receives every request. It consults handler mappings to find the right controller method, invokes it, and the method returns either a view name or, for REST, a serialized body.

For a view, a view resolver turns the name into a template that gets rendered. For REST, @ResponseBody (or @RestController) serializes the return value straight to the response, usually as JSON.

@Controller is the general web stereotype; its methods usually return a view name that a template engine renders. @RestController is @Controller plus @ResponseBody applied to every method, so return values are serialized directly to the response body.

Use @RestController for JSON APIs and @Controller when you're rendering server-side HTML views. Mixing them up is a common cause of getting a view-name string in your JSON response.

@RequestMapping maps a URL pattern (and optionally an HTTP method, headers, or content type) to a handler method or an entire controller class. The shortcuts @GetMapping, @PostMapping, @PutMapping, @DeleteMapping, and @PatchMapping are method-specific forms of it.

Prefer the shortcuts on methods for readability and put a shared base path in a class-level @RequestMapping.

@PathVariable binds a value embedded in the URL path (/users/42, the 42), so it's for identifying a resource. @RequestParam binds a query-string or form parameter (/users?role=admin, the role), so it's for filters and options.

Rule of thumb: identity in the path, refinement in the query. @RequestParam also supports defaults and required=false; path variables are part of the route and always present.

@RequestBody tells Spring to deserialize the incoming HTTP request body (usually JSON) into a method parameter object using a message converter like Jackson. @ResponseBody does the reverse: it serializes the return value into the response body instead of treating it as a view name.

@RestController applies @ResponseBody to every method, which is why REST controllers rarely write it explicitly.

JdbcTemplate is Spring's helper for raw JDBC. It handles the repetitive plumbing: opening and closing connections and statements, iterating result sets, and translating SQL exceptions into Spring's DataAccessException hierarchy, so you write only the query and the row mapping.

It sits below JPA and Spring Data. Reach for it when you want direct SQL control without hand-writing boilerplate.

Spring Data JPA lets you define a repository interface and get a working implementation for free. You extend JpaRepository, and Spring generates CRUD methods plus derived queries from method names like findByEmail at startup.

You write no implementation class. For anything the naming convention can't express, you add an @Query with JPQL or native SQL.

Spring Boot reads configuration from application.properties or application.yml, environment variables, command-line arguments, and profile-specific files, then merges them with a defined precedence. You inject values with @Value or, better, bind a group of them to a typed class with @ConfigurationProperties.

Profiles (application-dev.yml, application-prod.yml) switch configuration per environment. Secrets should come from the environment or a secret manager, never the committed file.

Profiles let you group beans and configuration per environment and activate a set at runtime. A bean or config class marked @Profile("prod") only loads when the prod profile is active, so dev, test, and prod can wire different implementations.

You activate a profile with spring.profiles.active in properties, an environment variable, or a command-line flag. Common use: an in-memory database for dev and the real one for prod.

@Value injects a value from external configuration into a field or parameter, resolving property placeholders like ${server.port} or Spring Expression Language expressions like #{2 * 60}. It reads from properties files, YAML, environment variables, and command-line arguments.

For a single loose value @Value is fine, but for a group of related settings @ConfigurationProperties binding a typed class is cleaner and easier to validate. Reaching for the typed binding on real config signals experience.

@SpringBootApplication is a shortcut for three annotations: @SpringBootConfiguration (a @Configuration class), @EnableAutoConfiguration (turn on Boot's auto-configuration), and @ComponentScan (scan this package and below for beans). One annotation on the main class sets up the whole application.

SpringApplication.run() in main() bootstraps the context: it creates the ApplicationContext, runs auto-configuration, starts the embedded server, and the app is live. That single run call is the entry point of every Boot service.

The container instantiates the bean, injects its dependencies, and then runs a series of callbacks before the bean is ready: aware interfaces, BeanPostProcessor before-init hooks, the init callback (@PostConstruct, then InitializingBean.afterPropertiesSet, then a custom init-method), and BeanPostProcessor after-init hooks. At shutdown it runs @PreDestroy, then DisposableBean.destroy, then a custom destroy-method.

The BeanPostProcessor hooks matter because that's where Spring itself applies proxies for AOP and transactions. Knowing the init order (@PostConstruct before afterPropertiesSet) signals real depth.

@PostConstruct marks a method to run once after the bean is constructed and its dependencies are injected, for initialization that needs the wired dependencies. @PreDestroy marks a method to run before the container removes the bean, for cleanup like closing connections.

They're the annotation-based, framework-neutral way to hook the lifecycle, preferred over implementing InitializingBean and DisposableBean because they don't couple your class to Spring interfaces.

AOP lets you apply behavior that cuts across many methods (logging, security checks, transactions, metrics) in one place instead of scattering it through every method. You write an aspect that says what to do (advice) and where to apply it (a pointcut).

Spring AOP is proxy-based: at startup it wraps matching beans in a proxy that runs the advice around the real method. That's the mechanism behind @Transactional and method-level security.

A join point is a point in execution where advice can apply; in Spring AOP that's always a method call. A pointcut is an expression that selects which join points to match. Advice is the code that runs (before, after, around). An aspect bundles pointcuts and advice into one module.

The types of advice: @Before, @After (finally), @AfterReturning, @AfterThrowing, and @Around, which is the most flexible because it wraps the call and controls whether it proceeds.

@Transactional wraps a method in a database transaction: Spring's AOP proxy opens a transaction before the method, commits if it returns normally, and rolls back on failure. By default it rolls back on unchecked exceptions and Errors, and commits on checked exceptions unless you set rollbackFor.

Because it's proxy-based, an internal self-call (this.other()) inside the same bean bypasses the proxy and the transaction won't apply. That gotcha is a favorite follow-up.

Propagation decides what happens when a transactional method calls another transactional method: does it join the existing transaction or start a new one? REQUIRED (the default) joins an existing transaction or starts one if none exists. REQUIRES_NEW always suspends any current transaction and starts an independent one.

Others: SUPPORTS (join if present, else run non-transactionally), MANDATORY (must already be in one), NESTED (a savepoint inside the current one). REQUIRES_NEW is the one to know: it's how you commit an audit log even if the outer transaction rolls back.

Isolation controls how much one transaction sees of another's uncommitted or in-flight changes, trading consistency against concurrency. From loosest to strictest: READ_UNCOMMITTED, READ_COMMITTED, REPEATABLE_READ, SERIALIZABLE.

DEFAULT uses the database's own default (often READ_COMMITTED). Each step up prevents another anomaly (dirty reads, non-repeatable reads, phantom reads) but costs concurrency. Naming the anomalies is what separates a memorized list from understanding.

Constructor injection makes dependencies explicit and required: you can't construct the object without them, they can be final (immutable), and you can build it in a plain unit test with new, no container needed. Field injection hides dependencies, allows partly-constructed objects, and needs reflection or the container to test.

Constructor injection also surfaces a design smell: if the constructor has eight parameters, the class is doing too much. Field injection quietly hides that.

If bean A needs B and B needs A through constructor injection, Spring can't build either first and throws a BeanCurrentlyInCreationException at startup. With setter or field injection it can sometimes break the cycle by injecting a partially-built proxy, but that's a smell, not a solution.

The real fix is to remove the cycle: extract the shared logic into a third bean, or rethink the responsibilities. @Lazy on one dependency can break the loop as a stopgap, but two classes that need each other usually signal a design problem.

Spring Security inserts a chain of servlet filters ahead of your app. Authentication filters establish who the caller is and store an Authentication in the SecurityContext; authorization then checks whether that principal may access the requested resource, via URL rules or method annotations like @PreAuthorize.

You configure it with a SecurityFilterChain bean: which paths are public, which need a role, how login works (form, HTTP Basic, JWT, OAuth2). The filter-chain model is what to explain first.

Use @RestControllerAdvice (or @ControllerAdvice) with @ExceptionHandler methods to catch exceptions across all controllers in one place and map each to a proper HTTP status and body. This keeps error handling out of individual handlers.

For per-controller handling you can put @ExceptionHandler methods directly on a controller. The advice class is the standard for consistent API error responses.

Spring integrates Bean Validation (Jakarta Validation): you annotate fields with constraints like @NotNull, @Size, @Email, then mark the controller parameter @Valid so the framework validates it before your method runs. A failure raises MethodArgumentNotValidException, which you map to a 400.

For rules that span fields or need context, write a custom ConstraintValidator or validate in the service layer. Combining declarative constraints with a global handler gives clean, consistent 400 responses.

Starters are curated dependency bundles: adding spring-boot-starter-web pulls in Spring MVC, Jackson, and an embedded Tomcat at compatible versions, so you don't assemble the dependency graph yourself. Auto-configuration then wires sensible beans based on what's on the classpath and your properties.

Auto-configuration backs off the moment you define your own bean of the same type, so it's a default, not a lock-in. Understanding that back-off behavior is the intermediate-level point.

Actuator adds production-ready operational endpoints to your app: health checks, metrics, environment info, thread dumps, and more, exposed over HTTP or JMX. /actuator/health and /actuator/metrics are the everyday ones, used by load balancers and monitoring.

It integrates with Micrometer to feed metrics to Prometheus, Datadog, and similar. Because these endpoints leak internals, you secure and selectively expose them in production.

The modern synchronous choice is RestClient (Spring 6.1+), a fluent blocking client that replaces the older RestTemplate. For reactive or high-concurrency non-blocking calls, WebClient from Spring WebFlux is the tool.

RestTemplate still works and appears in older code but is in maintenance mode. Picking RestClient for blocking code and WebClient for reactive is the current, correct answer.

They form a hierarchy. CrudRepository gives basic save, find, delete. PagingAndSortingRepository adds pagination and sorting on top. JpaRepository extends both and adds JPA-specific extras like flush, batch deletes, and returning List instead of Iterable.

In practice most code extends JpaRepository because it's the richest. Knowing the layering explains why some methods exist on one interface and not another.

Eager loading fetches an entity's associations immediately with the entity; lazy loading defers the fetch until you first access the association. Lazy is the sensible default for collections, but touching a lazy association after the persistence context closes throws LazyInitializationException.

The N+1 problem: loading N parents then firing one query per parent to load its children, so N+1 queries instead of one. The fix is a fetch join or an @EntityGraph to load parents and children in a single query.

Spring lets beans publish and listen for events in-process, decoupling the publisher from the handlers. You publish with ApplicationEventPublisher (or just return the event from an aggregate) and handle it with an @EventListener method. Handlers run synchronously by default, in the publisher's thread and transaction.

Add @Async to run a listener on another thread, and @TransactionalEventListener to run only after the surrounding transaction commits, which is the right way to send an email only if the order actually saved.

@Async on a method makes Spring run it on a separate thread pool and return immediately (void or a Future/CompletableFuture); you enable it with @EnableAsync. @Scheduled runs a method on a fixed rate, fixed delay, or cron expression, enabled with @EnableScheduling.

Both are proxy-based, so the same self-invocation gotcha as @Transactional applies: calling an @Async method from within the same bean runs it synchronously. Configure an explicit TaskExecutor rather than relying on the default.

By default a prototype injected into a singleton is resolved once, when the singleton is created, so you keep getting the same instance, which defeats the point. The container only creates a new prototype when it's asked, and a singleton's dependency is asked for exactly once.

Fixes: inject an ObjectProvider (or a Provider) and call getObject() each time you need a fresh one, use a @Lookup method that Spring overrides to return a new instance, or use scoped-proxy mode on the prototype. ObjectProvider is the clean, current choice.

Spring AOP proxies a bean one of two ways. If the bean implements an interface, it uses a JDK dynamic proxy that implements that interface. If it doesn't, or you force it, Spring uses CGLIB to generate a runtime subclass. Spring Boot defaults to CGLIB (proxy-target-class true) so proxying works regardless of interfaces.

The consequences experienced engineers cite: CGLIB can't proxy final classes or final methods, and both approaches only intercept external calls through the proxy, which is why an internal self-call skips the advice.

Because Spring AOP works through a proxy that wraps the bean. When an external caller invokes the method, the call goes through the proxy, which applies the transaction. But an internal call (this.method()) goes straight to the target instance and never touches the proxy, so no advice runs.

Fixes: move the transactional method to a separate bean and inject it, self-inject the proxy, or use AspectJ load-time weaving which weaves the advice into the bytecode and works for self-calls. Naming the mechanism, not just the symptom, is what's evaluated.

A BeanPostProcessor is a container extension point with two hooks that run for every bean, before and after its initialization callbacks. It can inspect, modify, or replace a bean, most importantly by wrapping it in a proxy.

This is how Spring itself applies AOP, @Transactional, and @Async: an internal BeanPostProcessor (like AbstractAutoProxyCreator) returns a proxy in the after-initialization hook. Understanding this explains where proxies come from in the lifecycle.

A BeanFactoryPostProcessor runs earlier: it operates on the bean definitions (the metadata) after they're loaded but before any bean is instantiated, so it can change a definition's properties. PropertySourcesPlaceholderConfigurer, which resolves ${...} placeholders, is one.

A BeanPostProcessor runs later, on the actual bean instances during initialization. Order matters: definitions first, instances second. Mixing them up is a common senior-level slip.

Auto-configuration classes are listed in each starter and gated by @Conditional annotations: @ConditionalOnClass (a type is on the classpath), @ConditionalOnMissingBean (you haven't defined your own), @ConditionalOnProperty (a property is set), and others. Boot evaluates these at startup and applies only the ones whose conditions pass.

@ConditionalOnMissingBean is why your bean overrides the default: define your own DataSource and the auto-configured one backs off. The Actuator 'conditions' report shows exactly which matched and why.

Create an @AutoConfiguration class with the conditional beans you want to contribute, register it in META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports, and gate everything with @ConditionalOnMissingBean so consumers can override. Bind settings through a @ConfigurationProperties class. Package it as a library other services depend on.

The design discipline that indicates senior: expose properties for everything configurable, back off when the consumer defines their own bean, and never force beans the app didn't ask for.

@Transactional is backed by a PlatformTransactionManager (like DataSourceTransactionManager or JpaTransactionManager). The AOP proxy asks the manager to begin a transaction, binds the connection or EntityManager to the current thread via a ThreadLocal (TransactionSynchronizationManager), runs your method, then commits or rolls back through the manager.

Thread-binding is the reason a transaction doesn't cross to another thread: an @Async method or a new thread starts with no bound transaction. That's a frequent production bug and a favorite deep follow-up.

Spring MVC is thread-per-request and blocking: simple to reason about, and fine until you have many concurrent connections mostly waiting on I/O. WebFlux is reactive and non-blocking, handling high concurrency on a small thread pool, which pays off for many slow or streaming downstream calls.

The honest trade-off: WebFlux demands a non-blocking stack end to end (reactive driver, WebClient) and reactive code is harder to write and debug. For most CRUD services with a blocking JDBC database, MVC is the right, simpler choice. With Java 21 virtual threads, blocking MVC scales further, narrowing WebFlux's niche.

Virtual threads are lightweight JVM threads that let blocking code scale to huge concurrency without the memory cost of platform threads. Spring Boot 3.2+ can run the web server and @Async executor on virtual threads with one property (spring.threads.virtual.enabled), so a normal blocking MVC app handles many more concurrent requests.

The practical effect: much of the pressure that pushed teams to reactive WebFlux eases, because you get high concurrency while keeping simple blocking code. The caveat is pinning: synchronized blocks around blocking calls can pin a virtual thread to its carrier, so those spots need attention.

Use the narrowest slice that proves what you need. A plain unit test with mocks needs no Spring context and is fastest. @WebMvcTest loads only the web layer to test controllers with a mocked service. @DataJpaTest loads only the persistence layer against an in-memory or Testcontainers database. @SpringBootTest boots the whole context for true end-to-end integration tests, and is the slowest.

The senior point is choosing the right slice: reaching for @SpringBootTest everywhere makes a slow, brittle suite. Testcontainers for a real database in integration tests is the current best practice over in-memory substitutes.

@Mock (Mockito) creates a bare mock with no Spring involvement, for unit tests. @MockBean (now @MockitoBean in newer Boot) creates a mock and replaces the matching bean inside the Spring context, so injected collaborators get the mock, for slice and integration tests. @Autowired pulls the real bean from the context.

The distinction that matters: @Mock lives outside Spring; @MockBean rewrites the running context, which also invalidates the cached context and can slow the suite if overused.

With graceful shutdown enabled, on a stop signal the server stops accepting new requests but lets in-flight ones finish within a timeout before the context closes and @PreDestroy runs. Boot enables it via server.shutdown=graceful plus a timeout property.

It matters in orchestrated environments (Kubernetes): during a rolling deploy, pods get SIGTERM, and without graceful shutdown you drop requests that were mid-flight. Pairing it with a readiness probe that fails first drains traffic cleanly.

Spring Cloud Config centralizes configuration in a Git-backed server that services fetch at startup, so config lives outside each deployable and changes without rebuilds. Service discovery (Eureka, or the platform's own DNS in Kubernetes) lets services find each other by name instead of hardcoded hosts.

The pragmatic note experienced engineers add: on Kubernetes much of this is handled by ConfigMaps, Secrets, and cluster DNS, so Spring Cloud Config and Eureka are less common than they were. Choosing platform-native tools when they exist is the mature answer.

Apply the standard patterns with Resilience4j: timeouts on every outbound call so a slow dependency can't hang your threads, retries with backoff for transient failures (idempotent calls only), a circuit breaker that stops hammering a failing dependency, and a bulkhead to cap concurrent calls so one slow service can't exhaust the pool.

The judgment part: retries without a circuit breaker amplify an outage, and retrying non-idempotent calls double-charges. Naming those failure modes is what a senior interview probes.

Measure first: the Actuator startup endpoint and the auto-configuration conditions report show where time goes. Then trim: exclude unneeded auto-configurations, prefer lazy initialization for rarely-used beans, and cut dependencies that drag in heavy starters. For serverless or fast-scaling workloads, Spring's AOT processing and GraalVM native images cut startup from seconds to milliseconds and shrink memory.

The trade-off with native images: build times grow and reflection needs hints, so it's worth it for cold-start-sensitive deployments, not every service.

Observe first: distributed tracing (Micrometer Tracing) to see where the time goes across services, and metrics on that endpoint's latency percentiles. If it's inside the service, take a thread dump or profile the live process to see whether it's CPU, lock contention, or waiting on I/O. Check the usual Spring suspects: N+1 queries from lazy loading, a missing connection-pool timeout, a synchronous external call without a timeout, or serialization of a huge payload.

Then fix at the right layer and confirm with the same metric. The structure, observe, hypothesize, verify, fix, confirm, matters more than any single tool; The methodology is.