Een bean scope bepaalt hoeveel instances de container aanmaakt en hoe lang ze leven. De lifecycle-callbacks laten je code draaien direct nadat een bean is geconstrueerd en vlak voordat hij wordt vernietigd.
Een bean scope bepaalt hoeveel instances de container aanmaakt en hoe lang ze leven. De lifecycle-callbacks laten je code draaien direct nadat een bean is geconstrueerd en vlak voordat hij wordt vernietigd.
@Service // standaard singleton — één gedeelde OrderService voor de hele app
public class OrderService { }
@Component
@Scope("prototype") // verse instance bij elke getBean/inject
public class ReportBuilder { }
De klassieke valkuil: een prototype in een singleton injecteren. De singleton wordt één keer bekabeld, dus houdt hij voor altijd één enkele prototype-instance vast — de belofte van "elke keer nieuw" breekt. Los het op met @Lookup, een ObjectProvider<ReportBuilder>, of een scoped-proxy.
@Component
public class ConnectionPool {
@PostConstruct // draait nadat dependencies zijn geïnjecteerd, vóór gebruik
public void open() { /* open sockets, warm caches */ }
@PreDestroy // draait bij een nette container-shutdown (alleen singletons)
public void close() { /* geef resources vrij */ }
}
Belangrijk: Spring roept @PreDestroy niet aan op prototype-beans — het geeft ze door en stopt met ze bij te houden, dus jij bent verantwoordelijk voor hun cleanup.
Dit scheidt mensen die Spring als magie behandelen van wie de container begrijpt. De bug van een singleton die een prototype vasthoudt is een favoriet interviewscenario omdat hij subtiel is en echte productiebugs veroorzaakt. Weten dat singletons stateless en thread-safe moeten zijn (ze worden over alle request-threads gedeeld) is de praktische conclusie waar interviewers naar luisteren.
Een bibliotheek met IT-sollicitatievragen met gedetailleerde antwoorden — van Junior tot Senior.
Doneren