To be, or not to be threadsafe! July 12, 2011 10:40 10 months ago
Hvad betyder det at være threadsafe? Et objekt eller klasse kan opretholde en gyldig tilstand overfor andre objekter og klasser, selv når de anvendes samtidig af flere tråde.
En servlet container er ikke dum
Der er meget magi mellem en web browser HTTP-request og den kode der eksekveres i service metoden. Servlet containeren forbinder denne magi med programmøren af en webapplikation. Containeren er ansvarlig for servlets init, destoy og service rækkefølgen af disse begivenheder i en bestemt livscyklus.
Netop servlet livscyklusen er et ofte overset emne. Årsagen til dets betydning er først og fremmest fordi så meget af servlet livscyklus er udenfor programmørens kontrol. Desværre kan man hellere ikke udnytte de gode egenskaber som ligger i Java Servlets.
Variabler
Lokale variabler er threadsafe – hver tråd får sin egen kopi af variablerne.
Dog kan det være at de objekter variabler peger på ikke er threadsafe – for eksempel, hvis en anden tråd har referencer til de samme objekter.
Normalt behøver du ikke bekymre dig om flertrådede adgang til lokale variabler, metode parametre, og returnere værdier. Disse variabler er placeret på Java stakken. I JVM’en er hver tråd tildelt sin egen Java stak. Ingen tråd kan se eller bruge lokale variabler, returnere værdier eller parametre, der tilhører en anden tråd ,,,
_ men du behøver at beskæftige dig med klasse variabler, når du bekymre dig om threadsafe’ness. Alle tråde deler den samme heap, og fordi heap’en er der hvor alle variabler er gemt, kan flere tråde forsøge at bruge samme objektets variabler samtidigt. _
the spec
’’’Multiple servlets executing request threads may have active access to the same session object at the same time. The container must ensure that manipulation of internal data structures representing the session attributes is performed in a threadsafe manner. The Developer has the responsibility for threadsafe access to the attribute objects themselves. This will protect the attribute collection inside the HttpSession object from concurrent access, eliminating the opportunity for an application to cause that collection to become corrupted. ‘’’
This is safe:
// guaranteed by the spec to be safe
request.getSession().setAttribute(“foo”, 1);
This is not safe:
HttpSession session = request.getSession();
Integer n = (Integer) session.getAttribute("foo");
// not thread safe
// another thread might be have got stale value between get and set
session.setAttribute("foo", (n == null) ? 1 : n + 1);
This is not guaranteed to be safe:
// no guarantee that same instance will be returned,
// nor that session will lock on "this"
HttpSession session = request.getSession();
synchronized (session) {
Integer n = (Integer) session.getAttribute("foo");
session.setAttribute("foo", (n == null) ? 1 : n + 1);
}
By Frank Vilhelmsen - 1 tag: java - 1 comment on To be, or not to be threadsafe! - Add comment
Andreas July 28, 2011 10:45 9 months ago
OMG! Jeg så lige et scenarie, som jeg er sikker på skaber problemer flere steder (du ved hvor) fordi der ikke skelnes mellem en session og det enkelte request…