Frage zu Threads

[WeirdAl]

Hi,
Im Bereich Threads habe ich recht wenig Erfahrung. Daher sorry falls diese Frage eigentlich zu den Anfängerfragen gehören sollte.
ich würde gerne wissen, ob ich unter den gleich folgenden "Umständen" in ein Threadproblem, d.h. mehrere Threads verändern das gleiche Objekt, laufen kann.

Der Einstieg erfolgt über ein Servlet, welches über keine Instanzvariablen verfügt. Alles geschieht in doPost. Innerhalb doPost erzeuge ich mir eine Objekt der Klasse A. Diese Klasse A enthält jetzt Instanzvariablen. Innerhalb des doPost werden diese Instanzvariablen manipuliert.

Pseudocode doPost:

// doPost ...
...

ClassAObject a = new ClassAObject();

a.setFile(file);
a.checkFile();
...

Pseudocode Klasse A:

...
// Instanzvariable
File tempFile = null;

public void setFile(File file){
this.tempFile = file;
}

public void checkFile(){
// checke manipuliere etc. das File
}
...

Im Prinzip denke ich eigentlich nicht das ich damit Probleme bekomme, da zwar durch den mehrfachen gleichzeitigen Zugriff auf das Servlet mehrere Threads gleichzeitig mit doPost arbeiten, aber alles was innerhalb doPost abläuft "atomar" sein sollte. Oder täusche ich mich da und der JVM optimiert innerhalb doPost rum und nutzt ab und ab das gleiche Objekt?

Ich habe gelesen das man generell, falls möglich, Instanzvariablen auf final setzen sollte. Final ermöglicht ja das einmalige setzen des Zeigers auf ein Objekt. Wenn ich jetzt das Tempfile im obigen Beispiel auf final setze, kann ich dem tempFile mit setFile noch einmalig das file in doPost zuordnen? Oder bekomme ich da Probleme, weil ich das tempFile schon mit null explizit initialisiert habe?

Gruß
Alex

 

[tfa]

ClassAObject a ist doch eine lokale Variable in der doPost-Methode. Verstehe ich das richtig? In dem Fall ist Threading überhaupt kein Problem, da ja jeder Thread nur ein einziges dieser Objekte zu Gesicht bekommt.

 

[WeirdAl]

Hi,
ja das denke ich eigentlich auch, aber ich wurde von Kollegen so durcheinander gebracht, dass ich nicht mehr wusste/weiß, ob es nicht trotzdem zu solchen Problemen kommen kann.
Irgendwann kam mal auf, das wenn doPost zB. 50 mal gleichzeitig ausgeführt wird, nicht 50 Klasse A Objekte erzeugt werden würden, sondern es vorkommen könnte, dass ein Thread eine andere Klasse A mitbenutzt.
Daher wollte ich sicher gehen und hier nachfragen

 

[maki]

tempFile ist ein Problem, falls es aus doPost oder doGet geändert wird.

Instanzvaribalen sollten in Servlets nur gelesen werden!

EDIT: Falsch gelesen, achte tempFile wäre eine Instanzvariable des Servlets, es gibt kein Problem.

 

[happy_robot]

ob es hier zu "thread-problemen" kommen kann vermag man hier mit diesen informationen nicht sagen zu können.
jedes servlet ist aber sozusagen ein eigener "thread" mit eigenem adressraum und eigenen variablen, insofern diese nicht als static deklariert sind.

schau mal unter:

- synchronized
- ThreadLocal

das sollte vielleicht helfen.

zudem gäbe es auch die möglichkeit variablen in einer static hashmap mit der sessionid als key zu speichern. der zugriff sollte aber über synchronized-methoden erfolgen.

 

[tfa]

Irgendwann kam mal auf, das wenn doPost zB. 50 mal gleichzeitig ausgeführt wird, nicht 50 Klasse A Objekte erzeugt werden würden, sondern es vorkommen könnte, dass ein Thread eine andere Klasse A mitbenutzt.

Also das ist Blödsinn. Wenn eine Methode 50 mal aufgerufen wird, werden auch 50 mal die lokalen Variablen bzw. deren Objekte angelegt. Egal ob da Threads im Spiel sind oder nicht.

 

[ms]

ob es hier zu "thread-problemen" kommen kann vermag man hier mit diesen informationen nicht sagen zu können.
jedes servlet ist aber sozusagen ein eigener "thread" mit eigenem adressraum und eigenen variablen, insofern diese nicht als static deklariert sind.

Nicht mal "sozusagen" ist ein Servlet ein Thread.
Es existiert nur ein Servlet zu Laufzeit welches von mehreren Threads benutzt wird. Daher sind gerade Instanzvariablen der Stolperstein (selber Adressraum), lokale Variablen dagegen machen keine Probleme.

ms

 

[happy_robot]

Nicht mal "sozusagen" ist ein Servlet ein Thread.

war (und bin) mir da nicht so ganz sicher.

public abstract class GenericServlet extends java.lang.Object

ein runnable wird auch von HttpServlet nicht implementiert. ich glaube das das servlet eher als dispatcher agiert.
ich weiß es aber nicht wirklich, erscheint mir abner sinnvoller als als thread.

 

[byte]

Ein Servlet ist kein Thread, hat ms doch geschrieben.
http://www.javaworld.com/javaworld/jw-07-2004/jw-0712-threadsafe.html?page=1

 

[happy_robot]

Nicht mal "sozusagen" ist ein Servlet ein Thread.

könnte man doppeldeutig verstehen. bin aber auch etwas erkältet und vielleicht heute etwas begriffsstutzig

Es existiert nur ein Servlet zu Laufzeit welches von mehreren Threads benutzt wird

diese würde ich aber wirklich in frage stellen. werde da aber mal nachforschen. das für mehrere tausende von anfragen in threads zu synchronisieren ist deutlich aufwendiger als das servlet zum dispatcher für threads zu machen. ist aber wie erwähnt meinerseits nur halbwissen. kann da durchaus falsch liegen.

 

[byte]

Das liegt gänzlich in der Verantwortung des Servlet Containers.

 

[happy_robot]

Das liegt gänzlich in der Verantwortung des Servlet Containers.

sehe ich genauso. deswegen interessiert's mich eigentlich auch nicht

 

[maki]

Mensch, steht doch alles in der Servlet Spec.

Wenn es kein STM (SingleThreadModel) Servlet ist, bekommt jeder Request seinen eigenen Thread.

 

[happy_robot]

Mensch, steht doch alles in der Servlet Spec.

Wenn es kein STM (SingleThreadModel) Servlet ist, bekommt jeder Request seinen eigenen Thread.

jeder request einen thread? na das schliesse ich auch mal aus. ich glaube aber du meines Thread/Session.

ich hätte es nur so formuliert:

"Es existiert nur ein Servlet welches für jede Session einen eigenen Thread erzeugt und alle Requests zu den zugehörigen Threads weiterleitet"

 

[Niki]

Ein Servlet erzeugt keinen Thread. Bei einem Request wird ein Thread erzeugt (bzw. ich nehme an es gibt einen Threadpool, da das erzeugen ja langsam ist) und dieser verwendet dann das Servlet. Mehrere Threads verwenden daher eine Instanz eines Servlets. Oder liege ich falsch?

 

[maki]

jeder request einen thread? na das schliesse ich auch mal aus. ich glaube aber du meines Thread/Session.

Ne, ich meinte schon ein Thread pro Request, dass diese aus einem Pool kommen sollten ist schon klar.
Aber da spielt die Session noch keine Rolle, wenn die Webapp keine Vorkehrungen getroffen hat, kann man zB auch aus einer Session gleichzeitig mehrere Requests abfeuern, das berüchtigte CTRL+N Problem

Aus der Spezifikation:

SRV.2.1 Request Handling Methods
The basic Servlet interface defines a service method for handling client requests.
This method is called for each request that the servlet container routes to an instance of a servlet.
The handling of concurrent requests to a Web application generally requires that the Web Developer design servlets that can deal with multiple threads executing within the service method at a particular time.
Generally the Web container handles concurrent requests to the same servlet by concurrent execution of the service method on different threads.

Das es natürlich ein Limit an Threads gibt ist schon klar, kann man zB beim Tomcat konfgurieren.

@ Niki: Sehe ich auch so.

 

[happy_robot]

Bei einem Request wird ein Thread erzeugt

die frage ist ja ob bei JEDEM request ein thread erzeugt wird. ich würde vermuten daß für einen request ohne sessionid ein thread erzeugt wird der dann die session repräsentiert.

wenn JEDER request einen thread erzeugen würde müsste man den sinn hier ernsthaft hinterfragen, da seine lebensdauer nur für die zeit des requests sinnvoll wäre. und wo werden denn dann zum beispiel session-beans gehalten? wie werden requests den einzelnen sessions zugeordnet. oder noch fundamentaler...was ist denn dann eine session überhaupt?