Performance-Tuning in Spring Boot dreht sich meist um die Datenbankgrenze: Connection Pooling, Caching und das Beseitigen des N+1-Query-Problems. Miss zuerst (Micrometer + Actuator-Metriken), dann greife den größten Kostenfaktor an.
Lazy-Assoziationen setzen eine Abfrage pro Parent ab und dann eine weitere pro Kind-Zugriff:
List<Order> orders = orderRepo.findAll();
(Order o : orders) {
o.getItems().size();
}
Behebe es, indem du die Assoziation in einem einzigen Join lädst:
@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 ist der Standard-Pool. Größer ist nicht besser – zu viele Verbindungen überlasten die DB. Eine gängige Formel startet nahe 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); }
Stütze es mit Redis (spring-boot-starter-data-redis) für einen geteilten Cache über Instanzen hinweg.
Senior-Interviews testen, ob du diagnostizierst, bevor du optimierst. Die stärksten Antworten benennen das Werkzeug, das den Engpass beweist (aktiviere spring.jpa.show-sql oder datasource-proxy, um Abfragen zu zählen, lies die p99-Latenz aus Actuator), erklären, warum ein überdimensionierter Pool schadet, und behandeln Caching als Korrektheitsproblem – veraltete Daten und Invalidierung – nicht nur als Geschwindigkeitsregler.
Eine Sammlung von IT-Interviewfragen mit ausführlichen Antworten — vom Junior bis zum Senior.
Spenden