Als data door meerdere threads wordt gelezen/geschreven moet je
altijd met een vorm van synchronisatie (synchronized of volatile) werken, anders heb je
geen garantie dat het werkt!
Dit is niet alleen vanwege memory barriers (het correct flushen van registers naar main memory en omgekeerd), waarbij het gedrag radicaal anders kan zijn afhankelijk van de hardware waar het programma op draait. De JIT compiler optimaliseert ook op basis van de synchronisatie-meta data en kan je programma stuk maken als je niet goed aangeeft dat data multi-threaded wordt gebruikt. Sinds Java 5 zijn de memory regels nog strenger op dit punt: als je niets aangeeft is je code vogelvrij.
Dat het niet alleen theorie is bewijst het voorbeeld van Alarmnummer wel aardig:
Alarmnummer schreef op vrijdag 26 mei 2006 @ 09:12:
[...]
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
| class BlaRunnable implements Runnable{
private boolean stop = false;
public void run(){
while(!stop){
System.out.println("bla");
}
}
public void stop(){
stop = true;
}
} |
Als je de Sun JVM met -server start (en dus de server JIT compiler activeert) en de methode wordt ge-JIT dan ziet de compiler dat de variabele van de conditie van de while lus niet wordt veranderd binnen de lus. Omdat er geen markering is aangebracht dat de stop variabele multi-threaded kan worden gemanipuleerd brengt de compiler de volgende optimalisatie aan:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
| class BlaRunnable implements Runnable{
private boolean stop = false;
public void run(){
if (!stop) {
while(true){
System.out.println("bla");
}
}
}
public void stop(){
stop = true;
}
} |
De compiler verplaatst het testen van de conditie zodat dit niet onnodig vaak hoeft te gebeuren, maar in dit geval resulteert het in een oneindige loop. Het gebeurt
alleen als de JIT compiler ingesteld is om dit te doen (bij Sun de Server JVM van Java 5 en hoger) en
alleen als de methode wordt ge-JIT (dus als je dit probeert moet je de methode eerst wel 10 keer aanroepen oid voordat de invocation threshold wordt overschreden). Je hebt er echter geen multi-proc machine of een 1 in de 1000000 keer scenario voor nodig: daarna gaat het gewoon stuk.
Moraal van het verhaal: gebruik altijd synchronisatie bij multi-threaded access. Dat het allemaal zo langzaam is is achterhaald: de JVM heeft inmiddels trucs als lock coarsening, en lock spinning en escape analysis om de impact minimaal te houden. Als je het niet doet dan kan het gewoon stuk gaan, op de meest vervelende en bizarre momenten (en misschien pas na een JVM upgrade).
:strip_exif()/u/13818/episodebutler_60x60.gif?f=community)
). Zodra de thread gestart is heb je eigenlijk gewoon twee threads. 1 waarin je orginele code draait en 1 waarin de run draait. Wat het exact voor de run methode betekent is afhankelijk van wat je in doSomethingElse doet en wat je in de run doet.
:strip_icc():strip_exif()/u/6143/rincewind.jpg?f=community)
:strip_exif()/u/31626/eend.gif?f=community)
/u/2305/crop653618cca8542_cropped.png?f=community)
:strip_icc():strip_exif()/u/12461/crop65b195553d948.jpg?f=community)
/u/92525/me.png?f=community)