Pambuka Model Memori Jawa
Model Memori Jawa (JMM) nggambarake prilaku benang ing lingkungan runtime Java. Model memori minangka bagéan saka semantik saka basa Jawa, lan njlèntrèhaké apa programmer bisa lan ora nyana nalika ngembangaken piranti lunak ora kanggo mesin Jawa tartamtu, nanging Jawa minangka kabèh.
Model memori Jawa asli (sing, utamané, nuduhake "memori percolocal"), dikembangaké ing 1995, dianggep gagal: akeh optimizations ora bisa digawe tanpa kelangan njamin keamanan kode. Ing tartamtu, ana sawetara opsi kanggo nulis multi-threaded "single":
- salah siji saben tumindak ngakses singleton (sanajan obyek wis digawe dangu, lan ora ana sing bisa ngganti) bakal nimbulaké kunci inter-thread;
- utawa ing kahanan tartamtu, sistem bakal ngetokake loner sing durung rampung;
- utawa ing kahanan tartamtu, sistem bakal nggawe loro loner;
- utawa desain bakal gumantung ing prilaku mesin tartamtu.
Mulane, mekanisme memori wis dirancang maneh. Ing taun 2005, nalika diluncurake Java 5, pendekatan anyar disedhiyakake, sing luwih apik nalika diluncurake Java 14.
Model anyar adhedhasar telung aturan:
Aturan #1 : Program single-threaded mbukak pseudo-sequentially. Iki tegese: ing kasunyatan, prosesor bisa nindakake sawetara operasi saben jam, ing wektu sing padha ngganti urutan, Nanging, kabeh dependensi data tetep, supaya prilaku ora beda-beda saka urutan.
Aturan nomer 2 : ora ana nilai sing ora ana. Maca sembarang variabel (kajaba non-molah malih dawa lan pindho, kang aturan iki bisa uga ora terus) bakal bali salah siji Nilai standar (nol) utawa soko ditulis ana dening printah liyane.
Lan aturan nomer 3 : acara liyane dileksanakake kanthi urutan, yen disambungake kanthi hubungan urutan parsial sing ketat "dilaksanakake sadurunge" ( kedadeyan sadurunge ).
Mengkono sadurunge
Leslie Lamport teka karo konsep Happens sadurunge . Iki minangka relasi urutan parsial sing ketat sing ditepungake ing antarane perintah atom (++ lan -- dudu atom) lan ora ateges "secara fisik sadurunge".
Dheweke ujar manawa tim nomer loro bakal "ngerti" babagan owah-owahan sing ditindakake dening sing pertama.
Contone, siji dieksekusi sadurunge liyane kanggo operasi kasebut:
Sinkronisasi lan monitor:
- Njupuk monitor ( cara kunci , wiwitan sing disinkronake) lan apa wae sing kedadeyan ing benang sing padha sawise.
- Bali monitor (cara mbukak kunci , mburi diselarasake) lan apa wae sing kedadeyan ing thread sing padha sadurunge.
- Mbalik maneh monitor banjur dijupuk nganggo benang liyane.
Nulis lan maca:
- Nulis menyang variabel apa wae banjur maca ing aliran sing padha.
- Kabeh ing thread padha sadurunge nulis kanggo variabel molah malih, lan nulis dhewe. maca molah malih lan kabeh ing thread padha sawise iku.
- Nulis menyang variabel molah malih banjur maca maneh. A nulis molah malih interaksi karo memori ing cara sing padha bali monitor, nalika diwaca kaya dijupuk. Pranyata yen siji thread nulis menyang variabel molah malih, lan liyane ketemu, kabeh sing ndhisiki nulis wis kaleksanan sadurunge kabeh sing teka sawise maca; ndeleng gambar.
Pangopènan obyek:
- Inisialisasi statis lan tumindak apa wae karo obyek apa wae.
- Nulis menyang lapangan final ing konstruktor lan kabeh sawise konstruktor. Minangka pangecualian, hubungan sing kedadeyan sadurunge ora nyambungake kanthi transitif menyang aturan liyane lan mula bisa nyebabake balapan antar benang.
- Sembarang karya karo obyek lan finalize () .
Layanan streaming:
- Miwiti thread lan kode apa wae ing thread.
- Zeroing variabel sing ana gandhengane karo benang lan kode apa wae ing benang.
- Kode ing thread lan gabung () ; kode ing thread lan isAlive () == palsu .
- ngganggu () Utas lan ndeteksi sing wis mandegake.
Mengkono sadurunge nuansa karya
Ngeculake monitor sing kedadeyan sadurunge kedadeyan sadurunge entuk monitor sing padha. Wigati dicathet yen iki minangka release, lan ora metu, yaiku, sampeyan ora perlu kuwatir babagan safety nalika nggunakake ngenteni.
Ayo ndeleng kepiye kawruh iki bakal mbantu kita mbenerake conto kita. Ing kasus iki, kabeh iku prasaja banget: mung mbusak mriksa njaba lan ninggalake sinkronisasi kaya. Saiki thread kapindho dijamin kanggo ndeleng kabeh owah-owahan, amarga iku mung bakal njaluk monitor sawise thread liyane ngeculake. Lan amarga dheweke ora bakal ngeculake nganti kabeh diwiwiti, kita bakal weruh kabeh owah-owahan bebarengan, lan ora kanthi kapisah:
public class Keeper {
private Data data = null;
public Data getData() {
synchronized(this) {
if(data == null) {
data = new Data();
}
}
return data;
}
}Nulis menyang variabel molah malih kedadeyan-sadurunge maca saka variabel sing padha. Owah-owahan sing wis kita lakoni, mesthi, mbenerake bug, nanging ndadekake sapa wae sing nulis kode asli bali saka ngendi asale - mblokir saben wektu. Tembung kunci molah malih bisa nyimpen. Nyatane, pratelan kasebut tegese nalika maca kabeh sing diumumake molah malih, kita bakal entuk nilai sing nyata.
Kajaba iku, kaya sing dakkandhakake sadurunge, kanggo lapangan sing molah malih, nulis tansah (kalebu dawa lan kaping pindho) minangka operasi atom. Titik penting liyane: yen sampeyan duwe entitas molah malih sing duwe referensi kanggo entitas liyane (contone, array, List utawa sawetara kelas liyane), banjur mung referensi kanggo entitas dhewe bakal tansah "seger", nanging ora kanggo kabeh ing. iku mlebu.
Dadi, bali menyang wedhus lanang sing ngunci dobel. Nggunakake volatile, sampeyan bisa ndandani kahanan kaya iki:
public class Keeper {
private volatile Data data = null;
public Data getData() {
if(data == null) {
synchronized(this) {
if(data == null) {
data = new Data();
}
}
}
return data;
}
}Kene kita isih duwe kunci, nanging mung yen data == null. Kita nyaring kasus sing isih ana nggunakake maca molah malih. Correctness wis menthekake dening kasunyatan sing nyimpen molah malih mengkono-sadurunge molah malih diwaca, lan kabeh operasi sing dumadi ing konstruktor katon kanggo sapa sing maca Nilai saka lapangan.