A Java memóriamodell ( JMM ) a szálak viselkedését írja le a Java futtatókörnyezetben . A memóriamodell a Java nyelv szemantikájának része, és leírja, hogy a programozó mire számíthat és mit nem szabad , ha nem egy adott Java gépre, hanem a Java egészére fejleszt szoftvert.
Az 1995-ben kifejlesztett eredeti Java memóriamodell (amely különösen a "perkolokális memóriát" tartalmazza), kudarcnak tekinthető: sok optimalizálás nem végezhető el anélkül, hogy ne veszítené el a kódbiztonság garanciáját. Többféle lehetőség is van a többszálú " egykezes " írására: [1]
A J2SE 5.0 (2004. szeptember 30.) egy új memóriamodellt vezetett be, amelyet a Java Community Process révén fejlesztettek ki JSR-133 néven [2] [3] . Jobban tükrözte a modern processzorok és fordítók működését, más nyelvek pedig a Java modellből vettek ötleteket. Létrehozásához Sarita Adwe , Jeremy Mason és Bill Pugh [4] adták hozzá a főszerepet .
A Java programozási nyelv lehetővé teszi többszálú programok írását. Mivel a Java számos processzoron és operációs rendszeren futhat, a szálak szinkronizálása különösen nehéz. Annak érdekében, hogy a programozó következtetéseket vonjon le a programok viselkedéséről, a Java fejlesztők úgy döntöttek, hogy egyértelműen meghatározzák az összes Java program különféle viselkedését.
A modern számítógépeken a kód a gyorsaság kedvéért nem abban a sorrendben fut le, ahogyan megírták. A permutációt a fordító, a processzor és a memória alrendszer végzi. A többprocesszoros gépeken minden magnak saját gyorsítótára lehet , amely nem szinkron a fő memóriával. Ez azt jelenti, hogy a különböző processzorok egyidejűleg ugyanannak a változónak különböző értékei lehetnek. Ha a szálak sokat kölcsönhatásba lépnek egymással, ez általában nem kívánatos: sok időbe telik, hogy lépést tartsunk a másik processzor tevékenységével.
Ezen túlmenően egyszálú környezetben elegendő megkövetelni, hogy a rendszer "pszeudo-szekvenciális" programvégrehajtást végezzen - egy megfigyelő számára, aki csak az I/O -t látja , úgy tűnik, hogy minden műveletet abban a sorrendben hajtanak végre, amelyben megjelentek a programban, még ha nem is. Azonban aki "be tud nézni" a számítógép memóriájába - egy másik szálat is beleértve - mindezek a "trükkök" észrevehetőek lesznek. Vegyünk két szálat, amelyek egyidejűleg hajtják végre az ilyen kódot ( xés ykezdetben nullákat).
| 1. adatfolyam | 2. adatfolyam |
|---|---|
| x = 1; | int r1 = y; |
| y=2; | int r2 = x; |
Ha nincsenek permutációk, és a 2. szál olvassa y=2, akkor garantáltan az lesz x=1: elvégre a to -be írás a to x-ba írás előtt történik y. Egy permutációval egy paradoxnak tűnő szituáció lehetségesnek bizonyul: r1=2, r2=0.
A JMM lehetővé teszi a többszálú programok ezt a viselkedését, de leírja, hogy mikor lehetséges az ilyen permutáció. Így a Java memóriamodell korlátozza a szálak interakcióját annak érdekében, hogy ne veszítse el az esetleges optimalizációkat, és egyúttal lehetővé tegye a többszálú programok megbízható és kiszámítható viselkedését ott, ahol szükséges. A programozó bármilyen következtetést levonhat a kód végrehajtásának sorrendjéről egy többszálú gépen, még a fordító, a processzor és a gyorsítótár által végzett optimalizálás ellenére is.
1. szabály: Az egyszálú programok pszeudoszekvenciálisan futnak. Ez azt jelenti: a valóságban a processzor órajelenként több műveletet is tud végrehajtani, egyidejűleg megváltoztatva azok sorrendjét, azonban minden adatfüggőség megmarad, így a viselkedés nem tér el a szekvenciálistól.
2. szabály: nincsenek a semmiből értékek. Bármely változó beolvasása (kivéve a nem- volatile longés -t double, amelyre ez a szabály nem biztos, hogy igaz) vagy az alapértelmezett értéket (nulla) adja vissza, vagy egy másik paranccsal odaírt valamit.
És a 3-as szabály: a többi eseményt sorrendben hajtják végre, ha azokat szigorú részleges sorrend köti össze „is végrehajtják előtt” ( angolul happens before ).
A „Happens before” ( angolul happens before ) egy szigorú részleges sorrendi viszony (antireflexív, antiszimmetrikus, tranzitív), amelyet az atomi ( ++és nem az atomi) parancsok közé vezettek be, Leslie Lamport-- találta ki, és nem azt jelenti, hogy „fizikailag korábban”. Ez azt jelenti, hogy a második csapat "tudni fogja" az első által végrehajtott változtatásokat.
Különösen az egyiket a másik előtt hajtják végre az ilyen műveleteknél (a lista nem teljes):
A többszálas és párhuzamos rendszerek elterjedt elterjedése miatt egyértelmű szemantikával rendelkező eszköztárra volt szükség. A Java memóriamodell volt az első kísérlet egy átfogó szálak közötti kommunikációs modell kidolgozására egy jelentősebb programozási nyelvhez [9] .
A C++03 -ban az egyetlen megjegyzés a többszálas kezeléssel kapcsolatban az, hogy a volatile-változók nem rendelkeznek hozzáférési sebesség-optimalizálással. Ez sem volt elég ahhoz, hogy az átrendező fordító/processzor teljes erejét kihasználja, és ne kapjon hibaüzenetet valamelyik parancs nem megfelelő végrehajtásával kapcsolatban. Hasonló memóriamodellt tartalmazott a C++11 [10] .
| Jáva | |
|---|---|
| Platformok | |
| Sun Technologies | |
| Harmadik fél kulcsfontosságú technológiái | |
| Sztori |
|
| Nyelvi tulajdonságok | |
| Szkriptnyelvek |
|
| Java konferenciák |
|