Prestandatrimning i Spring Boot handlar mestadels om gränsen mot databasen: connection pooling, caching och att döda N+1-frågeproblemet. Mät först (Micrometer + Actuator-mätvärden), och angrip sedan den största kostnaden.
Lata associationer gör en fråga per förälder, och sedan ytterligare en per åtkomst av barn:
List<Order> orders = orderRepo.findAll();
(Order o : orders) {
o.getItems().size();
}
Åtgärda det genom att hämta associationen i en enda 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 är standardpoolen. Större är inte bättre — för många anslutningar överbelastar databasen. En vanlig formel börjar nära 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); }
Backa den med Redis (spring-boot-starter-data-redis) för en delad cache över flera instanser.
Senior-intervjuer testar om du diagnostiserar innan du optimerar. De starkaste svaren namnger verktyget som bevisar flaskhalsen (aktivera spring.jpa.show-sql eller datasource-proxy för att räkna frågor, läs p99-latens från Actuator), förklarar varför en överdimensionerad pool skadar, och behandlar caching som ett korrekthetsproblem — inaktuella data och invalidering — inte bara som ett hastighetsreglage.
Ett bibliotek med IT-intervjufrågor och detaljerade svar — från Junior till Senior.
Donera