Ein Bean-Scope steuert, wie viele Instanzen der Container erstellt und wie lange sie leben. Die Lifecycle-Callbacks lassen dich Code direkt nach der Konstruktion einer Bean und kurz vor ihrer Zerstörung ausführen.
Ein Bean-Scope steuert, wie viele Instanzen der Container erstellt und wie lange sie leben. Die Lifecycle-Callbacks lassen dich Code direkt nach der Konstruktion einer Bean und kurz vor ihrer Zerstörung ausführen.
@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 { }
Die klassische Falle: einen Prototype in ein Singleton zu injizieren. Das Singleton wird einmal verdrahtet, sodass es für immer eine einzige Prototype-Instanz behält – das Versprechen „jedes Mal neu“ bricht. Behebe es mit @Lookup, einem ObjectProvider<ReportBuilder> oder einem 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 */ }
}
Wichtig: Spring ruft @PreDestroy bei Prototype-Beans nicht auf – es übergibt sie und hört auf, sie zu verfolgen, sodass du für ihre Aufräumarbeiten verantwortlich bist.
Das trennt Leute, die Spring als Magie behandeln, von denen, die den Container verstehen. Der Bug „Singleton hält einen Prototype“ ist ein beliebtes Interviewszenario, weil er subtil ist und echte Produktionsfehler verursacht. Zu wissen, dass Singletons zustandslos und thread-sicher sein müssen (sie werden über alle Request-Threads geteilt), ist die praktische Erkenntnis, auf die Interviewer horchen.
Eine Sammlung von IT-Interviewfragen mit ausführlichen Antworten — vom Junior bis zum Senior.
Spenden