Un bean scope contrôle le nombre d'instances que le conteneur crée et leur durée de vie. Les lifecycle callbacks vous permettent d'exécuter du code juste après la construction d'un bean et juste avant sa destruction.
Un bean scope contrôle le nombre d'instances que le conteneur crée et leur durée de vie. Les lifecycle callbacks vous permettent d'exécuter du code juste après la construction d'un bean et juste avant sa destruction.
@Service // singleton par défaut — un seul OrderService partagé pour toute l'application
public class OrderService { }
@Component
@Scope("prototype") // instance neuve à chaque getBean/injection
public class ReportBuilder { }
Le piège classique : injecter un prototype dans un singleton. Le singleton est câblé une seule fois, il conserve donc à jamais une unique instance de prototype — la promesse du « neuf à chaque fois » est rompue. Corrigez-le avec @Lookup, un ObjectProvider<ReportBuilder> ou un scoped-proxy.
@Component
public class ConnectionPool {
@PostConstruct // s'exécute après l'injection des dépendances, avant l'utilisation
public void open() { /* ouvre les sockets, préchauffe les caches */ }
@PreDestroy // s'exécute à l'arrêt propre du conteneur (singletons uniquement)
public void close() { /* libère les ressources */ }
}
Important : Spring n'appelle pas @PreDestroy sur les beans prototype — il les remet et cesse de les suivre, c'est donc à vous d'assurer leur nettoyage.
Cela sépare ceux qui prennent Spring pour de la magie de ceux qui comprennent le conteneur. Le bug du singleton contenant un prototype est un scénario d'entretien favori car il est subtil et cause de vrais bugs en production. Savoir que les singletons doivent être sans état et thread-safe (ils sont partagés entre tous les threads de requête) est l'enseignement pratique que les recruteurs guettent.
Une bibliothèque de questions d'entretien IT avec des réponses détaillées — du Junior au Senior.
Faire un don