Uno scope del bean controlla quante istanze crea il container e quanto a lungo vivono. Le callback del ciclo di vita ti permettono di eseguire codice subito dopo che un bean è stato costruito e appena prima che venga distrutto.
Uno scope del bean controlla quante istanze crea il container e quanto a lungo vivono. Le callback del ciclo di vita ti permettono di eseguire codice subito dopo che un bean è stato costruito e appena prima che venga distrutto.
@Service // singleton by default — one shared OrderService for the whole app
public class OrderService { }
@Component
@Scope("prototype") // fresh instance on every getBean/inject
public class ReportBuilder { }
La trappola classica: iniettare un prototype in un singleton. Il singleton viene collegato una sola volta, quindi mantiene per sempre una singola istanza del prototype — la promessa del "nuovo ogni volta" viene meno. Risolvilo con @Lookup, un ObjectProvider<ReportBuilder> o uno scoped-proxy.
@Component
public class ConnectionPool {
@PostConstruct // runs after dependencies are injected, before use
public void open() { /* open sockets, warm caches */ }
@PreDestroy // runs on graceful container shutdown (singletons only)
public void close() { /* release resources */ }
}
Importante: Spring non chiama @PreDestroy sui bean prototype — li consegna e smette di tracciarli, quindi la loro pulizia è responsabilità tua.
Questo distingue chi tratta Spring come magia da chi comprende il container. Il bug del singleton che mantiene un prototype è uno scenario da colloquio prediletto perché è sottile e causa bug reali in produzione. Sapere che i singleton devono essere stateless e thread-safe (sono condivisi tra tutti i thread di richiesta) è la conclusione pratica che gli intervistatori attendono.
Una raccolta di domande di colloquio IT con risposte dettagliate — da Junior a Senior.
Dona