Common Spring Boot Performance Anti-Patterns
Fast recall
Quick revision
Core answer
Whether you have practical experience shipping Spring Boot services and have encountered and fixed real-world performance issues beyond textbook examples.
Only listing generic Java anti-patterns rather than Spring-specific ones like eager bean initialization, auto-configuration overhead, or Jackson ObjectMapper recreation.
Mention Spring's lazy initialization flag, ObjectMapper singleton pattern, disabling unused auto-configurations, and the cost of AOP proxy chains in hot paths.
Interview-ready guide
Interview answer
The most common Spring Boot performance problems share a pattern: they're invisible in development (small data, low concurrency) and appear gradually in production as data and traffic grow.
N+1 queries — the most common
- Hibernate's lazy loading fetches associated entities with a separate SQL query per entity — loading 100 orders generates 101 queries (1 + 100 for items); the application appears to work correctly because all data is loaded, just with 100x more database round trips
- Fix:
JOIN FETCHin JPQL,@EntityGraph, or@BatchSize; enable SQL logging in development to detect N+1 before it reaches production;spring.jpa.show-sql=true
ObjectMapper creation per request
new ObjectMapper()is expensive — it scans annotations, configures serializers and deserializers, and initializes hundreds of internal maps; creating one per request adds 1-5ms of overhead per JSON operation- Fix: inject a shared
ObjectMapperbean; Spring Boot auto-configures one; use@Autowired ObjectMapper objectMapperinstead ofnew ObjectMapper()
Synchronous I/O on the main thread for parallelizable work
- Calling three downstream services sequentially when they could run in parallel triples the latency —
serviceA.call()takes 100ms;serviceB.call()takes 100ms;serviceC.call()takes 100ms; total = 300ms - Fix:
CompletableFuture.allOf(futureA, futureB, futureC).join()runs all three in parallel; total = max(100, 100, 100) = 100ms
Large queries without pagination
repository.findAll()on a table with millions of rows loads all rows into heap simultaneously — causes OutOfMemoryError or multi-second GC pauses- Fix:
Pageableparameter on repository methods;findAll(PageRequest.of(0, 100)); stream results withfindAllBy(Specification, Sort)returning aStreamfor large exports
Missing database indexes on foreign keys
- JPA generates foreign key columns but not indexes on them by default in many configurations — a
JOINon an unindexed FK causes a sequential scan on the larger table for every join - Fix: add explicit
@Indexannotations or create indexes in Flyway migrations for all frequently joined FK columns
Common Spring Boot Performance Anti-Patterns
Direct Answer
Common Spring Boot anti-patterns include N+1 queries, ObjectMapper recreation, synchronous blocking in reactive code, excessive AOP proxies, and loading all beans eagerly at startup.
Common Mistakes & Pitfalls
Only listing generic Java anti-patterns rather than Spring-specific ones like eager bean initialization, auto-configuration overhead, or Jackson ObjectMapper recreation.
Check your understanding
Answer these without looking back at the article.
- How do you measure Spring Boot application startup time?
- What Spring Boot actuator endpoints are useful for performance monitoring?
- How does Spring Boot 3 virtual threads support change performance characteristics?
Related interview prep categories
1Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.