In Java zijn de andere basisvariabelen atomair, behalve de 8-byte, 64-bits variabelen van Long en Double.
Het Java-opslagmodel vereist dat zowel ophaal- als opslagoperaties atomair zijn, maar voor niet-vluchtige lange en dubbele variabelen maakt de JVM het mogelijk om een 64-bits lees- of schrijfbewerkingen op te splitsen in twee 32-bits bewerkingen.
Als lezen en schrijven op verschillende threads plaatsvinden, kan het lezen van een niet-vluchtig type long resulteren in een hoge 32 bits van de ene waarde en een lage 32 bits van de andere.
Dus zelfs als je niet geeft om verlopen data, is het misschien niet veilig om gedeelde, veranderbare long- en dubbele variabelen te gebruiken in een multithreaded programma, tenzij ze vluchtig zijn verklaard of beschermd met een lock.
Over atomaire bewerkingen gesproken, betekent dit dat lezen en schrijven atomair zijn, zoals i=5; Dit is een atoomoperatie.
Als de werking van twee atomen echter samen wordt uitgevoerd, is deze niet noodzakelijkerwijs atomair, zoals eerst lezen en dan schrijven, dan is het mogelijk dat de variabele na het lezen is aangepast.
i++ is zo'n bewerking, eerst lezen en dan schrijven, dus de gehele variabele is atomair, niet dat i++ een atomaire bewerking is.
Wanneer je gebruikt voor (int i=0; i<10000; i++){System.out.print(i)}
Je zult merken dat ik uiteindelijk geen 10.000 druk en ongeveer 8-9 duizend druk.
Maar in het geval van multithreading, zelfs als de integervariabele atomair is, kunnen er threadveiligheidsproblemen ontstaan, wat een threadzichtbaarheidsprobleem is, dus je moet een vluchtige instructie toevoegen.
Deze modifier is een geforceerde variabele die elke keer uit het geheugen wordt gelezen en niet in registers wordt opgeslagen. |
Geplaatst op 05-04-2015 22:17:45
|
|
|
