Obseg beana nadzoruje, koliko instanc vsebnik ustvari in kako dolgo živijo. Povratni klici življenjskega cikla ti omogočajo, da zaženeš kodo takoj po konstrukciji beana in tik pred njegovim uničenjem.
Obseg beana nadzoruje, koliko instanc vsebnik ustvari in kako dolgo živijo. Povratni klici življenjskega cikla ti omogočajo, da zaženeš kodo takoj po konstrukciji beana in tik pred njegovim uničenjem.
@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 { }
Klasična past: injiciranje prototype v singleton. Singleton je povezan enkrat, zato za vedno hrani eno samo prototype instanco — obljuba "nov vsakič" se poruši. Popravi jo z @Lookup, ObjectProvider<ReportBuilder> ali scoped-proxyjem.
@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 */ }
}
Pomembno: Spring ne pokliče @PreDestroy na prototype beanih — preda jih in jih preneha slediti, zato ti prevzameš njihovo čiščenje.
To loči tiste, ki Spring obravnavajo kot čarovnijo, od tistih, ki razumejo vsebnik. Napaka singletona, ki hrani prototype, je priljubljen scenarij na razgovoru, ker je subtilna in povzroča resnične produkcijske napake. Vedeti, da morajo biti singletoni brez stanja in varni za nitenje (deljeni so med vsemi nitmi zahtev), je praktičen zaključek, ki ga izpraševalci poslušajo.
Knjižnica IT vprašanj za razgovore s podrobnimi odgovori — od začetnika do izkušenega.
Doniraj