2011-01-06 11 views
6

Wenn Sie Ihren Dienst im Singleton-Bereich in Ihrer Spring-Konfiguration definieren, was passiert, wenn mehr als ein Benutzer gleichzeitig versuchen, auf sie zuzugreifen (dh als Abhängigkeit in Ihren Controller) ? Sollte es Konflikte verursachen? Oder der IoC-Container wird den späteren Anruf bis zum ersten beenden? Wenn ja, sollte es die Performance in großen Anwendungen verlangsamen, was für mich nicht richtig klingt. Kann mir jemand eine richtige Antwort geben?Wenn Spring Singleton gleichzeitig auf mehrere Instanzen zugreift

BTW, wie ich mich erinnern kann, wenn es nicht ein Singleton ist, IoC Container wird einige Instanzen basierend auf der Anzahl der Anfragen Pool. Kann jemand das bestätigen?

Antwort

12

Was passiert, wenn mehrere Benutzer gleichzeitig versuchen, auf sie zuzugreifen (dh als Abhängigkeit, die in Ihren Controller injiziert wird)?

Auf eine Singleton-Bean kann mehrmals gleichzeitig zugegriffen werden. Deshalb muss es immer threadsicher sein.

Sollte es zu Konflikten kommen?

Nur wenn Sie nicht es thread-safe

Oder die IoC-Container zu machen, die späten Anruf bis zum ersten Ziel halten?

Nein, das


BTW schrecklich sein würde, wie ich mich erinnern kann, wenn es nicht ein Singleton ist ein, wird IoC-Container wenigen Fällen Pool auf der Anzahl von Anforderungen basiert. Kann jemand das bestätigen?

Frühling hat die folgenden Bereiche (see Bean Scopes reference):

  • singleton (nur eine Instanz pro Anwendung verwaltet)
  • prototype (eine neue Instanz für jede Injektion)
  • session (eine Instanz per HTTP-Sitzung, nur im Frühjahr MVC)
  • request (eine Instanz pro HTTP-Anfrage, nur im Frühjahr MVC)
  • global session (eine Instanz pro globaler HTTP-Sitzung, nur in Portlet-basierten Spring MVC)

auch:

Ab Frühling 3.0, ein Thread Umfang zur Verfügung steht, aber nicht registriert ist durch Standard.Weitere Informationen finden Sie in der Dokumentation für SimpleThreadScope.

Was Sie beschreiben, ist ein Objektpool. Im Frühjahr würde das als Prototyp-Bereich FactoryBean implementiert werden. Und intern würde es eine Bibliothek wie Apache Commons/Pool verwenden.

+0

Vielen Dank für die Antwort hatte. Was wäre die beste Methode, um die Singleton-Klasse sicher zu machen? Ich denke nicht, Sync synchronisieren Block wäre eine gute Idee, da es für die Leistung zu teuer ist. – Brolinuk

+0

@Brolinuk Manchmal brauchen Sie synchronisierte Blöcke, manchmal nicht. Lesen Sie [Java Concurrency in Practice] (http://www.javaconcurrencyinpractice.com/), um weitere Informationen zu erhalten. Grundsätzlich: Wenn Sie keinen veränderbaren Zustand haben, sind Sie normalerweise threadsicher. Wenn Sie dies tun, müssen Sie den Zugriff auf den veränderbaren Zustand synchronisieren. Es gibt auch eine [relevante SO-Frage] (http://stackoverflow.com/questions/1237980/java-5-concurrency-book-recommendations) –

4

Singletons sind genau das - Singletons. Eine Instanz wird vom Spring-Kontext verwaltet, und alle Anforderungen durchlaufen diese Instanz gleichzeitig. Es liegt an dir, das Thread-Safe zu machen.

Wenn Ihre Bean nicht threadsicher ist, sollten Sie nicht Singleton-fähige Beans verwenden. Mit Spring können Sie Anforderungs-, Sitzungs- und Prototypbereiche verwenden.

+1

+1 wenn ich Punkte für "bis zu Ihnen, um das thread-safe" – Kurru