Въведение в модела на паметта на Java
Моделът на паметта на Java (JMM) описва поведението на нишките в среда за изпълнение на Java. Моделът на паметта е част от семантиката на езика Java и описва Howво може и Howво не трябва да очаква програмистът, когато разработва софтуер не за конкретна Java машина, а за Java като цяло.
Оригиналният модел на паметта на Java (който по-специално се отнася до "percolocal memory"), разработен през 1995 г., се счита за провал: много оптимизации не могат да бъдат напequalsи, без да се загуби гаранцията за безопасност на codeа. По-специално, има няколко опции за писане на многонишков "единичен":
- or всеки акт на достъп до сингълтон (дори когато обектът е създаден преди много време и нищо не може да се промени) ще предизвика заключване между нишки;
- or при определен набор от обстоятелства системата ще издаде незавършен самотник;
- or при определен набор от обстоятелства системата ще създаде двама самотници;
- or дизайнът ще зависи от поведението на конкретна машина.
Следователно механизмът на паметта е преработен. През 2005 г., с пускането на Java 5, беше представен нов подход, който беше допълнително подобрен с пускането на Java 14.
Новият модел се основава на три правила:
Правило #1 : Програмите с една нишка се изпълняват псевдопоследователно. Това означава: в действителност процесорът може да изпълнява няколко операции на часовник, като в същото време променя техния ред, но всички зависимости на данните остават, така че поведението не се различава от последователното.
Правило номер 2 : няма стойности от нищото. Четенето на която и да е променлива (с изключение на енергонезависимите long и double, за които това правило може да не важи) ще върне or стойността по подразбиране (нула), or нещо, записано там от друга команда.
И правило номер 3 : останалите събития се изпълняват по ред, ако са свързани със строга частична връзка на реда „изпълнява се преди“ ( се случва преди ).
Случва се преди
Лесли Лампорт излезе с концепцията за Случва се преди . Това е стриктна връзка на частичен ред, въведена между атомарните команди (++ и -- не са атомарни) и не означава "физически преди".
В него се казва, че вторият отбор ще бъде "в течение" за промените, напequalsи от първия.
Например, едното се изпълнява преди другото за такива операции:
Синхронизация и монитори:
- Заснемане на монитора ( метод на заключване , синхронизирано стартиране) и всичко, което се случва в същата нишка след него.
- Връщането на монитора ( отключване на метод , край на синхронизирано) и всичко, което се случва в същата нишка преди него.
- Връщане на монитора и след това заснемането му от друга нишка.
Писане и четене:
- Писане във всяка променлива и след това четене в същия поток.
- Всичко в една и съща нишка преди запис в променливата volatile и самото писане. volatile read и всичко в същата тема след него.
- Записване в променлива променлива и след това четене отново. Нестабилният запис взаимодейства с паметта по същия начин като връщането на монитора, докато четенето е като улавяне. Оказва се, че ако една нишка пише в volatile променлива и втората я намери, всичко, което предхожда записа, се изпълнява преди всичко, което идва след четенето; виж снимката.
Поддръжка на обекта:
- Статична инициализация и всяHowви действия с всяHowви екземпляри на обекти.
- Писане в крайните полета в конструктора и всичко след конструктора. По изключение релацията случва-преди не се свързва транзитивно с други правила и следователно може да предизвика надпревара между нишките.
- Всяка работа с обекта и finalize() .
Услуга за поточно предаване:
- Стартиране на нишка и всеки code в нишката.
- Нулиране на променливи, свързани с нишката и всеки code в нишката.
- Код в нишка и join() ; code в нишката и isAlive() == false .
- interrupt() нишката и открива, че тя е спряла.
Случва се преди работа нюанси
Освобождаването на случва-преди монитор възниква преди придобиването на същия монитор. Струва си да се отбележи, че това е освобождаването, а не изходът, тоест не е нужно да се притеснявате за безопасността, когато използвате изчакване.
Нека видим How това знание ще ни помогне да коригираме нашия пример. В този случай всичко е много просто: просто премахнете външната проверка и оставете синхронизацията такава, Howвато е. Сега втората нишка е гарантирана, че ще види всички промени, защото ще получи монитора едва след като другата нишка го освободи. И тъй като той няма да го пусне, докато всичко не бъде инициализирано, ще видим всички промени наведнъж, а не поотделно:
public class Keeper {
private Data data = null;
public Data getData() {
synchronized(this) {
if(data == null) {
data = new Data();
}
}
return data;
}
}Записването в променлива променлива се случва - преди четене от същата променлива. Промяната, която направихме, разбира се, поправя грешката, но връща този, който е написал оригиналния code, там, откъдето е дошъл - блокира всеки път. Ключовата дума volatile може да спаси. Всъщност въпросното твърдение означава, че когато четем всичко, което е обявено за volatile, винаги ще получим действителната стойност.
Освен това, Howто казах по-рано, за летливи полета писането винаги е (включително дълго и двойно) атомарна операция. Друг важен момент: ако имате променлив обект, който има препратки към други обекти (например масив, списък or няHowъв друг клас), тогава само препратката към самия обект винаги ще бъде „свежа“, но не и към всичко в то входящо.
И така, да се върнем към нашите овни с двойно заключване. Използвайки volatile, можете да коригирате ситуацията по следния начин:
public class Keeper {
private volatile Data data = null;
public Data getData() {
if(data == null) {
synchronized(this) {
if(data == null) {
data = new Data();
}
}
}
return data;
}
}Тук все още имаме заключване, но само ако data == null. Ние филтрираме останалите случаи с помощта на непостоянно четене. Коректността се гарантира от факта, че volatile store се случва - преди volatile read и всички операции, които се случват в конструктора, са видими за всеки, който чете стойността на полето.