L'ottimizzazione delle prestazioni in Spring Boot riguarda per lo più il confine con il database: connection pooling, caching ed eliminazione del problema delle query N+1. Misura prima (metriche Micrometer + Actuator), poi attacca il costo maggiore.
Le associazioni lazy emettono una query per parent, poi una ulteriore per ogni accesso al figlio:
List<Order> orders = orderRepo.findAll();
(Order o : orders) {
o.getItems().size();
}
Risolvilo recuperando l'associazione in un unico 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 è il pool predefinito. Più grande non è meglio — troppe connessioni mettono in crisi il DB. Una formula comune parte vicino a 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); }
Appoggialo a Redis (spring-boot-starter-data-redis) per una cache condivisa tra le istanze.
I colloqui senior verificano se diagnostichi prima di ottimizzare. Le risposte più forti nominano lo strumento che dimostra il collo di bottiglia (abilita spring.jpa.show-sql o datasource-proxy per contare le query, leggi la latenza p99 da Actuator), spiegano perché un pool sovradimensionato fa male e trattano il caching come un problema di correttezza — dati obsoleti e invalidazione — non come una semplice manopola della velocità.
Una raccolta di domande di colloquio IT con risposte dettagliate — da Junior a Senior.
Dona