Java Memory Model ( JMM ) beskriver opførslen af tråde i Java runtime-miljøet . Hukommelsesmodellen er en del af Java-sprogets semantik og beskriver, hvad en programmør kan og ikke bør forvente, når han udvikler software ikke til en specifik Java-maskine, men for Java som helhed.
Den originale Java-hukommelsesmodel (som især omfatter "perkolokal hukommelse"), udviklet i 1995, betragtes som en fiasko: mange optimeringer kan ikke foretages uden at miste garantien for kodesikkerhed. Især er der flere muligheder for at skrive flertrådede " enhånds ": [1]
J2SE 5.0 (30. september 2004) introducerede en ny hukommelsesmodel udviklet gennem Java Community Process kaldet JSR-133 [2] [3] . Det afspejlede bedre, hvordan moderne processorer og compilere fungerer, og andre sprog har taget ideer fra Java-modellen. De vigtigste bidrag til dens skabelse blev leveret af Sarita Adwe , Jeremy Mason og Bill Pugh [4] .
Programmeringssproget Java giver dig mulighed for at skrive flertrådede programmer. Fordi Java kan køre på en bred vifte af processorer og operativsystemer, er trådsynkronisering særlig vanskelig. For at programmøren kunne drage nogle konklusioner om programmernes adfærd, besluttede Java-udviklerne klart at definere de forskellige adfærdsmønstre for alle Java-programmer.
På moderne computere udføres kode for hastighedens skyld ikke i den rækkefølge, den er skrevet i. Permutationen udføres af compileren, processoren og hukommelsesundersystemet. På multiprocessormaskiner kan hver kerne have sin egen cache , der ikke er synkron med hovedhukommelsen. Det betyder, at forskellige processorer kan have forskellige værdier af den samme variabel på samme tid. Når tråde interagerer meget med hinanden, er dette normalt uønsket: det tager meget tid at holde sig ajour med, hvad den anden processor har gjort.
Derudover er det i et enkelttrådsmiljø nok at kræve, at systemet skal "pseudo-sekventiel" programafvikling - for en observatør, der kun ser I/O , vil det se ud til, at alle handlinger udføres i den rækkefølge, de optrådte i programmet, selvom de ikke er det. Men enhver, der kan "kigge" ind i computerens hukommelse - inklusive en anden tråd - vil alle disse "tricks" kunne mærkes. Overvej to tråde, der samtidigt udfører en sådan kode ( xog yoprindeligt nuller).
| Stream 1 | Stream 2 |
|---|---|
| x = 1; | int r1 = y; |
| y=2; | int r2 = x; |
Hvis der ikke er nogen permutationer, og tråd 2 læses y=2, er det garanteret x=1: Når alt kommer til alt, bliver skrivningen til xudført før skrivningen til y. Med en permutation viser sig en tilsyneladende paradoksal situation at være mulig: r1=2, r2=0.
JMM'en tillader denne opførsel af flertrådede programmer, men beskriver, hvornår sådanne permutationer er mulige. Java-hukommelsesmodellen pålægger således begrænsninger for interaktionen af tråde for ikke at miste mulige optimeringer og samtidig tillade flertrådede programmer at opføre sig pålideligt og forudsigeligt, hvor det er nødvendigt. Programmøren kan drage alle konklusioner om rækkefølgen, hvori koden udføres på en multithreaded -maskine, selv på trods af de optimeringer, der er foretaget af compileren, processoren og cachen.
Regel #1: Enkeltrådede programmer kører pseudo-sekventielt. Dette betyder: i virkeligheden kan processoren udføre flere operationer pr. ur, samtidig med at den ændrer deres rækkefølge, dog forbliver alle dataafhængigheder, så adfærden adskiller sig ikke fra sekventiel.
Regel nummer 2: Der er ingen ud af ingenting værdier. Læsning af enhver variabel (undtagen ikke- volatile longog double, for hvilke denne regel muligvis ikke er sand) vil returnere enten standardværdien (nul) eller noget skrevet der af en anden kommando.
Og regel nummer 3: resten af begivenhederne udføres i rækkefølge, hvis de er forbundet med et strengt delordreforhold "er udført før" ( engelsk sker før ).
"Happens before" ( engelsk happens before ) er en streng partiel ordensrelation (antirefleksiv, antisymmetrisk, transitiv) introduceret mellem atomiske kommandoer ( ++og --ikke atomiske), opfundet af Leslie Lamport og betyder ikke "fysisk før". Det betyder, at det andet hold vil være "vidende" om ændringerne foretaget af det første.
Især udføres den ene før den anden for sådanne operationer (listen er ikke udtømmende):
På grund af den udbredte introduktion af flertrådede og parallelle systemer var der behov for et værktøjssæt med klar semantik. Java-hukommelsesmodellen var det første forsøg på at udvikle en omfattende inter-thread kommunikationsmodel for et større programmeringssprog [9] .
I C++03 er den eneste bemærkning om multithreading, at volatile-variabler ikke har nogen adgangshastighedsoptimeringer. Dette var heller ikke nok til at bruge den fulde kraft af omarrangeringskompileren/processoren og ikke få en fejl relateret til udførelse af en eller anden kommando. En lignende hukommelsesmodel blev inkluderet i C++11 [10] .
| Java | |
|---|---|
| Platforme | |
| Sun Technologies | |
| Nøgle tredjepartsteknologier | |
| Historie |
|
| Sprogegenskaber | |
| Scripting sprog |
|
| Java konferencer |
|