2010-02-10 2 views

Antwort

21

Fact verwenden: Es gibt nur 1 Instanz eines Servlets in Webapp ist Lebenszeit. Es wird beim Start von WebApp erstellt und beim Herunterfahren der WebApp zerstört. Siehe auch this answer für eine grobe Interpretation.

So wurde es unter allen Anfragen (Threads) geteilt. Wenn Sie Anfrage- oder Sitzungsbereichsdaten als Instanzvariablen (oder schlimmer noch, als static) Variablen zuweisen, ist dies definitiv kein Threadsicher, da sie dann unter allen Anfragen (Threads) von allen Benutzern (Sitzungen) anwendungsweit geteilt werden. Sie müssen sie nur als lokale Methodenvariablen zuweisen, damit sie sicher bleiben. Also:

public class MyServlet extends HttpServlet { 

    private Object thisIsNOTThreadSafe; 

    protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { 
     Object thisIsThreadSafe; 

     thisIsNOTThreadSafe = request.getParameter("foo"); // BAD!! Shared among all requests! 
     thisIsThreadSafe = request.getParameter("foo"); // OK, this is thread safe. 
    } 
} 

Das ist im Grunde alles, was Sie berücksichtigen müssen, wenn Sie Servlets mit Threadsicherheit im Auge behalten.

Dann gibt es Sitzungsattribute (HttpSession), die unter mehreren Anfragen desselben Benutzers gemeinsam genutzt werden können, aber in der realen Welt müssen Sie sich keine Gedanken über die Synchronisierung des Sitzungszugriffs machen. In der Regel werden dort nur benutzerspezifische Daten wie der eingeloggte Benutzer, benutzerspezifische Einstellungen, der Warenkorb usw. hinterlegt. Sie müssen lediglich sicherstellen, dass Sie keine reinen Anforderungsbereichsdaten in den Sitzungsumfang eingeben. Es würde sich in mehreren Browserfenstern/Tabs innerhalb derselben Sitzung widerspiegeln.

Dann gibt es Anwendung (ServletContext) Attribute, die unter allen Benutzern Applicationwide freigegeben sind, aber Sie normalerweise nur Konstanten und andere statische Daten dort, wie die Webapp-Konfiguration, DAO Factory, Drop-down-Liste Inhalte und so weiter.Dies alles kann übrigens mit einem gemacht werden, siehe auch this answer für ein grundlegendes Beispiel. Sie müssen lediglich sicherstellen, dass Sie keine reinen Anforderungs- oder Sitzungsdaten im Anwendungsbereich der Anwendung angeben.

+0

Eine Frage bezüglich "ein Servlet in der Web-App Lebenszeit" - Ich dachte, das war ein gepooltes Objekt, so Je nach Auslastung kann es im Ermessen der Servlet-Engine mehr als eins geben. Ist das nicht wahr? – duffymo

+0

Nur wenn es implementiert (gemäß Servlet 2.4 veraltet) 'SingleThreadModel'. – BalusC

+0

@BalusC: Vielen Dank Sir, diese Antwort hat mir endlich geholfen. Ich habe meine Frage gelöscht und Ihre Antwort aktualisiert. Es gibt niemanden wie dich in Java. Nochmals eine Million. –

0

Meinst du in einem Kontext im Gegensatz zu anderen Java-Anwendungen? Es gibt wirklich keinen großen Unterschied. Jede Anfrage an ein Servlet bewirkt, dass der Container einen neuen Thread ausgibt, um damit umzugehen. Daher müssen Instanzvariablen innerhalb des Servlets Thread-sicher sein. Es ist besser, all Ihr Geschäft mit lokalen Variablen in den Methoden doGet/doPost() zu behandeln. Es gibt einen Fehler, den ich mir vorstellen kann. Bei Sitzungsvariablen kann es sein, dass der Benutzer zwei Browserfenster geöffnet hat, die beide auf Ihre Anwendung verweisen. In diesem Fall müssten Sie auch mit dem Sitzungsumfang auf Thread-Sicherheit achten.

1

Wow, das ist eine geladene Frage.

Um es einfach auszudrücken, müssen Sie sicherstellen, dass der Zugriff auf freigegebene Daten sorgfältig synchronisiert wird. Z. B. können Sie den Zugriff auf eine statische Variable mit einem Mutex oder einer synchronisierten Funktion synchronisieren.

Beachten Sie, dass Sie möglicherweise auch auf höheren Ebenen synchronisieren müssen, wenn Sie atomare Transaktionen benötigen, die mehrere gemeinsam genutzte Ressourcen gleichzeitig ändern.

Entwerfen einer gleichzeitigen Anwendung ist nicht einfach, und es gibt kein Wundermittel (leider). Ich empfehle das Buch "Java Concurrency in Practice" für weitere Informationen zum Schreiben von Sicherheitscode.

16
+2

Ich denke, dass Punkt 4 ziemlich (1-3) überholt. :) –

+3

Nun, es gibt ein Bedürfnis für einige grundlegende Kenntnisse, bevor Sie etwas gutes Denken – Bozho

+0

+1 für Element 4 machen können :) – BalusC

Verwandte Themen