Un scope de bean controlează câte instanțe creează containerul și cât timp trăiesc. Callback-urile de ciclu de viață îți permit să rulezi cod imediat după ce un bean este construit și chiar înainte să fie distrus.
Un scope de bean controlează câte instanțe creează containerul și cât timp trăiesc. Callback-urile de ciclu de viață îți permit să rulezi cod imediat după ce un bean este construit și chiar înainte să fie distrus.
@Service // singleton implicit — un singur OrderService partajat pentru toată aplicația
public class OrderService { }
@Component
@Scope("prototype") // instanță proaspătă la fiecare getBean/inject
public class ReportBuilder { }
Capcana clasică: injectarea unui prototype într-un singleton. Singleton-ul este legat o singură dată, așa că păstrează o singură instanță prototype pentru totdeauna — promisiunea „nou de fiecare dată" se rupe. Rezolvă cu @Lookup, un ObjectProvider<ReportBuilder> sau un scoped-proxy.
@Component
public class ConnectionPool {
@PostConstruct // rulează după ce dependențele sunt injectate, înainte de utilizare
public void open() { /* deschide socket-uri, preîncălzește cache-uri */ }
@PreDestroy // rulează la oprirea grațioasă a containerului (doar singleton-uri)
public void close() { /* eliberează resurse */ }
}
Important: Spring nu apelează @PreDestroy pe bean-urile prototype — le predă și încetează să le urmărească, așa că tu deții curățarea lor.
Asta îi separă pe cei care tratează Spring ca magie de cei care înțeleg containerul. Bug-ul singleton-care-ține-un-prototype este un scenariu preferat la interviu deoarece este subtil și provoacă bug-uri reale în producție. Faptul că știi că singleton-urile trebuie să fie fără stare și thread-safe (sunt partajate între toate thread-urile de cerere) este concluzia practică pe care intervievatorii o ascultă.
O bibliotecă de întrebări de interviu IT cu răspunsuri detaliate — de la Junior la Senior.
Donează