Als ich anfing, mit Spring zu arbeiten, war eines der Konzepte, das mich am meisten faszinierte, die Idee der Bean-Scopes. Spring stellt verschiedene Bean-Bereiche bereit, die den Lebenszyklus von Beans bestimmen, die im Spring-Container erstellt werden. Zwei der am häufigsten verwendeten Bereiche sind Singleton und Prototype. Das Verständnis dieser Bereiche ist für das Entwerfen effizienter und effektiver Spring-Anwendungen von entscheidender Bedeutung. Lassen Sie mich Ihnen daher erklären, was ich darüber gelernt habe.

Spring Bean Scopes verstehen

In Spring ist eine Bean ein Objekt, das vom Spring IoC-Container (Inversion of Control) instanziiert, zusammengestellt und verwaltet wird. Der Bean-Bereich bezieht sich auf den Lebenszyklus des Beans – wie und wann die Bean-Instanzen erstellt werden und wie lange sie gültig sind.

Spring bietet mehrere Bean-Bereiche, aber die beiden, auf die ich mich konzentrieren werde, sind:

• Singleton-Bereich
• Prototypumfang

Jeder Bereich hat seine spezifischen Anwendungsfälle, und die Auswahl des richtigen Bereichs kann erhebliche Auswirkungen auf das Verhalten und die Leistung Ihrer Anwendung haben.

Der Singleton-Bereich

Der Singleton-Bereich ist der Standardbereich in Spring und ich verwende ihn am häufigsten. Wenn eine Bean mit dem Singleton-Bereich definiert ist, bedeutet dies, dass der Spring-Container nur eine Instanz dieser Bean erstellt und diese einzelne Instanz im gesamten Anwendungskontext gemeinsam genutzt wird.

Wie es funktioniert

Wenn ich eine Bean als Singleton deklariere, erstellt Spring die Bean-Instanz bei der ersten Anforderung, entweder beim Start des Anwendungskontexts oder beim ersten Verweis darauf. Danach gibt jede weitere Anfrage für diese Bean dieselbe Instanz zurück.

Hier ist ein einfaches Beispiel:

@Configuration
public class AppConfig {
    @Bean
    public MyService myService() {
        return new MyService();
    }
}

In diesem Beispiel ist myService() eine Singleton-Bean. Jedes Mal, wenn ich eine MyService-Bean aus dem Spring-Kontext anfordere, erhalte ich dieselbe Instanz.

Anwendungsfälle für Singleton Beans

Ich habe festgestellt, dass der Singleton-Bereich ideal für zustandslose Beans ist – solche, die keine clientspezifischen Informationen enthalten. Beispiele sind:

• Dienstklassen: Typischerweise enthalten diese Klassen Geschäftslogik, die in der gesamten Anwendung gemeinsam genutzt werden kann, ohne dass separate Instanzen erforderlich sind.
• DAO-Klassen: Da sie normalerweise mit der Datenbank interagieren und keinen clientspezifischen Status beibehalten, ist eine einzelne Instanz ausreichend.

Vorteile und Überlegungen

Der Hauptvorteil von Singleton-Beans ist die Speichereffizienz. Durch die Wiederverwendung einer einzelnen Instanz verbraucht die Anwendung weniger Speicher und der Aufwand für das Erstellen und Zerstören von Objekten wird minimiert. Bei Singleton-Bohnen, die ihren Zustand beibehalten, ist jedoch Vorsicht geboten. Wenn eine Singleton-Bean versehentlich einen Status hält (z. B. Instanzvariablen), kann dieser Status von mehreren Clients gemeinsam genutzt werden, was zu potenziellen Dateninkonsistenzen führen kann.

Der Prototyp-Bereich

Im Gegensatz zu Singleton erstellt der Prototype-Bereich jedes Mal eine neue Bean-Instanz, wenn die Bean aus dem Spring-Container angefordert wird. Als ich davon erfuhr, war mir klar, dass Prototype-Beans für Szenarien nützlich sind, in denen ich für jede Verwendung eine neue Instanz benötige.

Wie es funktioniert

Wenn eine Bean mit dem Prototype-Bereich definiert ist, gibt Spring jedes Mal eine neue Instanz zurück, wenn die Bean angefordert wird. So könnte ich eine Prototype-Bean definieren:

@Configuration
public class AppConfig {
    @Bean
    @Scope("prototype")
    public MyService myService() {
        return new MyService();
    }
}

In diesem Beispiel erstellt Spring jedes Mal, wenn ich die MyService-Bean aus dem Spring-Kontext anfordere, eine neue Instanz von MyService.

Anwendungsfälle für Prototyp-Beans

Prototyp-Beans sind besonders nützlich, wenn es um Stateful-Beans geht – solche, die einen clientspezifischen Zustand beibehalten oder für jede Verwendung eine einzigartige Konfiguration erfordern. Einige typische Anwendungsfälle sind:

• Befehlsobjekte: Wenn ich ein Muster wie Command umsetze, bei dem jeder Befehl separat ausgeführt wird und seinen eigenen Status beibehält, ist eine Prototype-Bean die richtige Wahl.
• Session oder Request Scoped Beans: In Webanwendungen können Beans, die spezifisch für eine Benutzersitzung oder Anforderung sind, als Prototyp definiert werden, um sicherzustellen, dass für jeden Benutzer oder jede Anforderung eine neue Instanz erstellt wird.

Vorteile und Überlegungen

Der Hauptvorteil der Verwendung von Prototype-Beans ist die Flexibilität, die sie beim Erstellen neuer Instanzen bietet. Dies ist besonders nützlich, wenn es um zustandsbehaftete Objekte geht. Es gibt jedoch einen Kompromiss in Bezug auf Leistung und Ressourcenverbrauch. Da jedes Mal eine neue Instanz erstellt wird, kann dies zu einem höheren Speicherverbrauch und einer häufigeren Speicherbereinigung führen. Darüber hinaus verwaltet Spring im Gegensatz zu Singleton-Beans nicht den Lebenszyklus von Prototyp-Beans über die Erstellung hinaus, sodass ich die Zerstörung und Bereinigung dieser Beans manuell durchführen muss.

Singleton vs. Prototype: Auswahl des richtigen Scopes

Eine der wichtigsten Entscheidungen, die ich beim Entwerfen einer Spring-Anwendung treffen muss, ist die Wahl zwischen Singleton- und Prototype-Bereich. Hier ist eine Zusammenfassung der Faktoren, die ich berücksichtige:

• Statefulness: Wenn die Bean zustandslos ist, ist Singleton normalerweise die beste Wahl. Für Stateful Beans ist Prototype besser geeignet.
• Ressourcenverwaltung: Singleton-Beans sind speichereffizienter, da nur eine Instanz verwaltet wird. Prototyp-Beans bieten zwar mehr Flexibilität, verbrauchen aber mehr Ressourcen.
• Lebenszyklusmanagement: Singleton-Beans werden während ihres gesamten Lebenszyklus vom Spring-Container verwaltet. Im Gegensatz dazu muss ich den gesamten Lebenszyklus von Prototype-Beans verwalten.

Praxisbeispiel

Lassen Sie mich ein praktisches Szenario bereitstellen, das dabei helfen kann, zu verdeutlichen, wann die einzelnen Bereiche verwendet werden sollten. Angenommen, ich erstelle eine Online-Shopping-Anwendung.

• Warenkorbdienst: Dieser Dienst wäre normalerweise zustandslos und ein guter Kandidat für eine Singleton-Bean. Es ist nicht erforderlich, jedes Mal eine neue Instanz zu erstellen, und derselbe Dienst kann mehrere Anfragen verarbeiten.
• Auftragsverarbeitung: Andererseits wäre das Order-Objekt, das die Bestellung eines Kunden darstellt, zustandsbehaftet und enthält spezifische Details zu dieser Bestellung. Daher sollte es sich um eine Prototype-Bean handeln, sodass jede Bestellung von einer separaten Instanz der Order-Klasse verarbeitet wird.

Mischbereiche: Ein Wort der Vorsicht

Eine Sache, die ich auf die harte Tour gelernt habe, ist, dass das Mischen von Singleton- und Prototype-Beans zu unerwarteten Problemen führen kann. Beispielsweise kann das Einfügen einer Prototype-Bean in eine Singleton-Bean dazu führen, dass die Singleton-Bean immer dieselbe Instanz der Prototype-Bean verwendet. Um dies zu vermeiden, füge ich normalerweise einen Provider ein oder verwende die @Lookup-Annotation, um sicherzustellen, dass jedes Mal, wenn sie benötigt wird, eine neue Instanz der Prototype-Bean erstellt wird.

@Service
public class SingletonService {

    @Autowired
    private Provider myPrototypeServiceProvider;

    public void usePrototypeService() {
        MyPrototypeService prototypeService = myPrototypeServiceProvider.get();
        prototypeService.execute();
    }
}

In diesem Beispiel stellt myPrototypeServiceProvider.get() sicher, dass bei jedem Aufruf innerhalb der Singleton-Bean eine neue Instanz von MyPrototypeService erstellt wird.

Auf Wiedersehen !

Das Verständnis der Nuancen der Singleton- und Prototype-Bean-Bereiche in Spring war auf meiner Reise als Entwickler von entscheidender Bedeutung. Beide Bereiche bieten je nach Anwendungsfall deutliche Vorteile, und die Wahl des richtigen Bereichs kann erhebliche Auswirkungen auf die Leistung und das Design einer Anwendung haben.

Meiner Erfahrung nach ist Singleton aufgrund seiner Effizienz und Einfachheit der erste Anwendungsbereich für die meisten Beans, während Prototype für die Sonderfälle reserviert ist, in denen ich jedes Mal eine neue Instanz benötige. Indem ich den Zustand meiner Beans und deren Verwendung innerhalb der Anwendung sorgfältig abwäge, kann ich fundierte Entscheidungen treffen, die zu besseren, wartbareren Spring-Anwendungen führen.