bean-ის scope განსაზღვრავს, რამდენ ინსტანციას ქმნის container და რამდენ ხანს ცოცხლობს ის. სასიცოცხლო ციკლის callback-ები საშუალებას გაძლევს, კოდი გაუშვა bean-ის აშენებისთანავე და მისი განადგურების წინ.
bean-ის scope განსაზღვრავს, რამდენ ინსტანციას ქმნის container და რამდენ ხანს ცოცხლობს ის. სასიცოცხლო ციკლის callback-ები საშუალებას გაძლევს, კოდი გაუშვა bean-ის აშენებისთანავე და მისი განადგურების წინ.
@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 { }
კლასიკური ხაფანგი: prototype-ის singleton-ში inject-ვა. singleton ერთხელ კავშირდება, ამიტომ ის სამუდამოდ ერთ prototype ინსტანციას ინახავს — „ყოველ ჯერზე ახალი" დაპირება ტყდება. გამოასწორე @Lookup-ით, ObjectProvider<ReportBuilder>-ით ან 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 */ }
}
მნიშვნელოვანია: Spring @PreDestroy-ს prototype bean-ებზე არ იძახებს — ის მათ გადასცემს და თვალყურის დევნებას წყვეტს, ამიტომ მათ დასუფთავებას შენ ფლობ.
ეს განასხვავებს იმათ, ვისთვისაც Spring ჯადოქრობაა, იმათგან, ვისაც container ესმის. singleton-რომელიც-prototype-ს-ინახავს ბაგი საყვარელი საინტერვიუო სცენარია, რადგან ის დახვეწილია და რეალურ production ბაგებს იწვევს. იმის ცოდნა, რომ singleton-ები უმდგომარეო და thread-safe უნდა იყოს (ისინი ყველა request thread-ს შორის იზიარება), არის ის პრაქტიკული დასკვნა, რომელსაც ინტერვიუერები ელოდებიან.
IT გასაუბრების კითხვების ბიბლიოთეკა დეტალური პასუხებით — Junior-დან Senior-მდე.
შემოწირულობა