Ydeevnetuning i Spring Boot handler mest om databasegrænsen: connection pooling, caching og at dræbe N+1-forespørgselsproblemet. Mål først (Micrometer + Actuator-metrikker), angrib derefter den største omkostning.
Lazy associations udsteder én forespørgsel per parent og derefter én mere per barneadgang:
List<Order> orders = orderRepo.findAll();
(Order o : orders) {
o.getItems().size();
}
Ret det ved at hente associationen i et enkelt join:
@Query("SELECT o FROM Order o JOIN FETCH o.items") // one query, items eagerly loaded
List<Order> findAllWithItems();
// Or @EntityGraph(attributePaths = "items") on the repository method.
HikariCP er standard-poolen. Større er ikke bedre — for mange connections får DB'en til at tage skade. En almindelig formel starter nær cores * 2:
spring:
datasource:
hikari:
maximum-pool-size: 10 # match DB capacity, not thread count
connection-timeout: 3000 # fail fast instead of piling up requests
@Cacheable(value = "products", key = "#id") // serve from cache after first load
public Product findById(Long id) { return repo.findById(id).orElseThrow(); }
@CacheEvict(value = "products", key = "#p.id") // invalidate on write
public Product update(Product p) { return repo.save(p); }
Understøt det med Redis (spring-boot-starter-data-redis) for en delt cache på tværs af instanser.
Senior-interviews tester, om du diagnosticerer, før du optimerer. De stærkeste svar nævner værktøjet, der beviser flaskehalsen (aktivér spring.jpa.show-sql eller datasource-proxy for at tælle forespørgsler, aflæs p99-latens fra Actuator), forklarer hvorfor en overdimensioneret pool skader, og behandler caching som et korrekthedsproblem — forældede data og invalidering — ikke blot en hastighedsknap.
Et bibliotek af IT-interviewspørgsmål med detaljerede svar — fra Junior til Senior.
Donér