Et bean-scope styrer, hvor mange instanser containeren opretter, og hvor længe de lever. Lifecycle-callbacks lader dig køre kode lige efter, at en bean er konstrueret, og lige før den destrueres.
Et bean-scope styrer, hvor mange instanser containeren opretter, og hvor længe de lever. Lifecycle-callbacks lader dig køre kode lige efter, at en bean er konstrueret, og lige før den destrueres.
@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 { }
Den klassiske fælde: at injicere en prototype ind i en singleton. Singletonen forbindes én gang, så den beholder en enkelt prototype-instans for altid — løftet om "ny hver gang" brydes. Ret det med @Lookup, en ObjectProvider<ReportBuilder> eller en 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 */ }
}
Vigtigt: Spring kalder ikke @PreDestroy på prototype-beans — den overdrager dem og holder op med at spore dem, så du ejer deres oprydning.
Dette adskiller folk, der behandler Spring som magi, fra dem, der forstår containeren. Bug'en med en singleton, der holder en prototype, er et yndet interviewscenarie, fordi den er subtil og forårsager reelle produktionsbugs. At vide, at singletons skal være stateless og thread-safe (de deles på tværs af alle request-tråde), er den praktiske pointe, interviewere lytter efter.
Et bibliotek af IT-interviewspørgsmål med detaljerede svar — fra Junior til Senior.
Donér