Просмотр кода страницы Модель памяти Java

'''Модель памяти Java''' ({{lang-en|Java Memory Model}}, {{lang-en2|JMM}}) описывает поведение [[поток выполнения|потоков]] в [[виртуальная машина Java|среде исполнения Java]]. Модель памяти — часть [[семантика языка программирования|семантики]] языка Java, и описывает, на что может и на что не должен рассчитывать [[программист]], разрабатывающий ПО не для конкретной Java-машины, а для Java в целом.

Исходная модель памяти Java (к которой, в частности, относится «потоколокальная память»), разработанная в 1995 году, считается неудачной: многие оптимизации невозможно провести, не потеряв гарантию безопасности кода. В частности, есть несколько вариантов написать многопоточную «[[Одиночка (шаблон проектирования)|одиночку]]»:<ref>{{Cite web |url=http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html |title=The "Double-Checked Locking is Broken" Declaration<!-- Заголовок добавлен ботом --> |access-date=2013-07-21 |archive-date=2012-03-06 |archive-url=https://web.archive.org/web/20120306104259/http://www.cs.umd.edu/%7Epugh/java/memoryModel/DoubleCheckedLocking.html |deadlink=no }}</ref>
* либо каждый акт доступа к одиночке (даже когда объект давно создан, и ничего уже не может измениться) будет вызывать [[мьютекс|межпоточную блокировку]];
* либо при определённом стечении обстоятельств система выдаст недостроенного одиночку;
* либо при определённом стечении обстоятельств система создаст две одиночки;
* либо конструкция будет зависеть от особенностей поведения той или иной машины.

{{seealso|Double checked locking}}

В [[J2SE]] 5.0 (30 сентября 2004) появилась новая модель памяти, разработанная через [[Java Community Process]] под названием JSR-133<ref name="Goetz2">{{cite web
 |url         = http://www-128.ibm.com/developerworks/library/j-jtp03304
 |title       = Fixing the Java Memory Model, Part 2
 |date        = 2004-02-24
 |last        = Goetz
 |first       = Brian
 |accessdate  = 2010-10-18
 |archiveurl  = https://web.archive.org/web/20070108223309/http://www-128.ibm.com/developerworks/library/j-jtp03304/
 |archivedate = 2007-01-08
 |deadlink    = yes
}}</ref><ref>{{cite web
 |url         = http://www.cs.umd.edu/~pugh/java/memoryModel/jsr-133-faq.html
 |title       = JSR 133 (Java Memory Model) FAQ
 |author      = Jeremy Manson and Brian Goetz
 |quote       = ''The Java Memory Model describes what behaviors are legal in multithreaded code, and how threads may interact through memory. It describes the relationship between variables in a program and the low-level details of storing and retrieving them to and from memory or registers in a real computer system. It does this in a way that can be implemented correctly using a wide variety of hardware and a wide variety of compiler optimizations.''
 |date        = 2004-02
 |accessdate  = 2010-10-18
 |archiveurl  = https://www.webcitation.org/6JO7fySxb?url=http://www.cs.umd.edu/~pugh/java/memoryModel/jsr-133-faq.html
 |archivedate = 2013-09-04
 |deadlink    = no
}}</ref>. Она лучше отражала принципы работы современных процессоров и компиляторов, и другие языки брали идеи из модели Java. Основной вклад в её создание внесли [[Адве, Сарита Викрам|Сарита Адве]], Джереми Мейсон и {{нп5|Пью, Уиллиам|Билл Пью||William Pugh (computer scientist)}}<ref>{{Книга|издательство=Pearson Education|isbn=978-0-13-326032-8|автор=James Gosling, Bill Joy, Guy L. Jr. Steele, Gilad Bracha, Alex Buckley|заглавие=The Java Language Specification, Java SE 7 Edition|год=2013}}</ref>.

== Предпосылки ==

Язык программирования [[Java]] позволяет писать многопоточные программы. Поскольку Java может работать на самых разных процессорах и ОС, синхронизация потоков особенно затрудняется. Чтобы программист мог сделать какие-то выводы о поведении программ, разработчики Java решили чётко определить различные варианты поведения всех программ на Java.

На современных компьютерах код ради скорости выполняется не в том порядке, в котором написан. Перестановка выполняется компилятором, процессором и подсистемой памяти. На многопроцессорных машинах каждое ядро может иметь свой [[Кэш процессора|кэш]], не синхронный с основной памятью. А значит, у разных процессоров могут быть одновременно разные значения одной и той же переменной. Когда потоки много взаимодействуют друг с другом, это обычно нежелательно: чтобы быть в курсе сделанного другим процессором, нужно много времени.

К тому же в однопоточной среде достаточно потребовать от системы «псевдопоследовательного» выполнения программы — наблюдателю, который видит только [[ввод-вывод]], будет казаться, что все действия выполняются в том порядке, в котором они появились в программе, даже если это не так. Однако любому, кто сможет «заглянуть» в память компьютера — в том числе другому потоку — все эти «трюки» будут заметны. Рассмотрим два потока, которые одновременно выполняют такой код (<code>x</code> и <code>y</code> изначально нули).

{| class="wikitable"
|-
! Поток 1
! Поток 2
|-
| x = 1;
| int r1 = y;
|-
| y = 2;
| int r2 = x;
|}

Если нет перестановок, а поток 2 считал <code>y=2</code>, гарантированно должно быть <code>x=1</code>: ведь запись в <code>x</code> выполняется прежде, чем запись в <code>y</code>. С перестановкой оказывается возможна и, казалось бы, парадоксальная ситуация: <code>r1=2</code>, <code>r2=0</code>.

Такое поведение многопоточных программ модель JMM разрешает, но описывает, когда такие перестановки возможны. Таким образом, модель памяти Java накладывает ограничения на взаимодействие потоков, чтобы не потерять возможные оптимизации и в то же время дать возможность многопоточным программам вести себя надёжно и предсказуемо там, где это нужно. Программист может делать какие-либо заключения о том, в каком порядке выполняется код на [[Многопоточность|многопоточной]] машине, даже несмотря на оптимизации, проводимые компилятором, процессором и кэшем.

== Модель памяти ==

Правило № 1: однопоточные программы исполняются псевдопоследовательно. Это значит: в реальности процессор может выполнять несколько операций за такт, заодно изменив их порядок, однако все зависимости по данным остаются, так что поведение не отличается от последовательного.

Правило № 2: нет невесть откуда взявшихся значений. Чтение любой переменной (кроме не-<code>volatile</code> <code>long</code> и <code>double</code>, для которых это правило может не выполняться) выдаст либо значение по умолчанию (ноль), либо что-то, записанное туда другой командой.

И правило № 3: остальные события выполняются по порядку, если связаны отношением строгого частичного порядка «выполняется прежде» ({{lang-en|happens before}}).

=== «Выполняется прежде» ===
[[Файл:HappensBeforeRu.svg|thumb|260px|В двух потоках нашлась цепочка «выполняется прежде» (обозначена символом строгого частичного порядка <math>\prec</math>), поэтому <code>println</code> выведет корректное значение.]]
«Выполняется прежде» ({{lang-en|happens before}}) — отношение [[Отношение порядка|строгого частичного порядка]] (антирефлексивное, антисимметричное, транзитивное), введённое между атомарными командами (<code>++</code> и <code>--</code> не атомарны), придуманное [[Лэмпорт, Лесли|Лесли Лэмпортом]] и не означающее «физически прежде». Оно значит, что вторая команда будет «в курсе» изменений, проведённых первой.

В частности, одно выполняется прежде другого для таких операций (список не исчерпывающий):
* Синхронизация и [[Монитор (синхронизация)|мониторы]]:
** Захват монитора (начало <code>synchronized</code>, метод <code>lock</code>) и всё, что после него в том же потоке.
** Возврат монитора (конец <code>synchronized</code>, метод <code>unlock</code>) и всё, что перед ним в том же потоке.
*** Таким образом, оптимизатор может заносить строки в синхроблок, но не наружу.
** Возврат монитора и последующий захват другим потоком.
* Запись и чтение:
** Любые зависимости по данным (то есть запись в любую переменную и последующее чтение её же) в одном потоке.
** Всё, что в том же потоке перед записью в <code>volatile</code>-переменную, и сама запись.
** <code>volatile</code>-чтение и всё, что после него в том же потоке.
** Запись в <code>volatile</code>-переменную и последующее считывание её же<ref name="Goetz2" /><ref>{{Cite web |url=http://gee.cs.oswego.edu/dl/cpj/jmm.html |title=Synchronization and the Java Memory Model<!-- Заголовок добавлен ботом --> |access-date=2013-07-21 |archive-date=2013-05-11 |archive-url=https://web.archive.org/web/20130511002150/http://gee.cs.oswego.edu/dl/cpj/jmm.html |deadlink=no }}</ref>. Таким образом, <code>volatile</code>-запись делает с памятью то же, что возврат монитора, а чтение — то же, что захват<ref>{{Cite web |url=http://g.oswego.edu/dl/jmm/cookbook.html |title=The JSR-133 Cookbook<!-- Заголовок добавлен ботом --> |accessdate=2013-07-18 |archiveurl=https://web.archive.org/web/20130925080251/http://g.oswego.edu/dl/jmm/cookbook.html |archivedate=2013-09-25 |deadlink=yes }}</ref>. А значит: если один поток записал в <code>volatile</code>-переменную, а второй обнаружил это, всё, что предшествует записи, выполняется раньше всего, что идёт после чтения; см. иллюстрацию.
*** Для объектных переменных (например, <code>volatile List x;</code>) столь сильные гарантии выполняются для ссылки на объект, но не для его содержимого.
* Обслуживание объекта:
** Статическая инициализация и любые действия с любыми экземплярами объектов.
** Запись в <code>final</code>-поля в конструкторе<ref>Ниоткуда, кроме как из конструктора, в <code>final</code>-поля писать нельзя.</ref> и всё, что после конструктора. Как исключение из всеобщей транзитивности, это соотношение ''happens-before'' не соединяется транзитивно с другими правилами и поэтому может вызвать межпоточную гонку<ref>{{Cite web |url=http://cheremin.blogspot.com/2011/12/final.html |title=>рабочие заметки: Гарантии для final-полей<!-- Заголовок добавлен ботом --> |access-date=2013-07-22 |archive-date=2015-01-16 |archive-url=https://web.archive.org/web/20150116141045/http://cheremin.blogspot.com/2011/12/final.html |deadlink=no }}</ref>.
** Любая работа с объектом и <code>finalize()</code>.
* Обслуживание потока:
** Запуск потока и любой код в потоке.
** Зануление переменных, относящихся к потоку, и любой код в потоке.
** Код в потоке и <code>join()</code>; код в потоке и <code>isAlive() == false</code>.
** <code>interrupt()</code> потока и обнаружение факта останова.

== Влияние ==

Из-за повсеместного внедрения многопоточных и параллельных систем потребовался инструментарий с чёткой семантикой. Модель памяти Java стала первой попыткой разработать исчерпывающую модель межпоточного взаимодействия для крупного языка программирования<ref>{{cite web
 |url         = http://www.ibm.com/developerworks/library/j-jtp02244.html
 |title       = Fixing the Java Memory Model, Part 1
 |date        = 2004-02-24
 |last        = Goetz
 |first       = Brian
 |accessdate  = 2008-02-17
 |archiveurl  = https://web.archive.org/web/20090813123211/http://www.ibm.com/developerworks/library/j-jtp02244.html
 |archivedate = 2009-08-13
 |deadlink    = yes
}}</ref>.

В [[C++03]] единственное замечание о многопоточности — для <code>volatile</code>-переменных не проводить никаких оптимизаций, связанных с ускорением доступа. Этого тоже не хватало, чтобы задействовать всю мощь переставляющего компилятора/процессора и не получить ошибку, связанную с внеочередным выполнением какой-то команды. Сходная модель памяти вошла в [[C++11]]<ref>{{cite web
 |url         = http://www.hpl.hp.com/personal/Hans_Boehm/c++mm/
 |title       = Threads and memory model for C++
 |last        = Boehm
 |first       = Hans
 |accessdate  = 2008-02-17
 |archiveurl  = https://www.webcitation.org/6JO7hl8jp?url=http://www.hpl.hp.com/personal/Hans_Boehm/c++mm/
 |archivedate = 2013-09-04
 |deadlink    = yes
}}</ref>.

== См. также ==
* {{iw|Модель памяти (информатика)|Модель памяти|en|Memory model (programming)}}
* [[Модель памяти Intel x86]]
* [[Модель памяти в языке Си]]

== Примечания ==
{{примечания}}

== Ссылки ==
* [http://www-128.ibm.com/developerworks/library/j-jtp02244.html Java theory and practice: Fixing the Java Memory Model, part 1] {{webarchive |url=https://web.archive.org/web/20090813123211/http://www.ibm.com/developerworks/library/j-jtp02244.html |date=2009-08-13}} — An article describing problems with the original Java memory model.
* [http://www-128.ibm.com/developerworks/library/j-jtp03304/ Java theory and practice: Fixing the Java Memory Model, part 2] {{webarchive |url=https://web.archive.org/web/20070108223309/http://www-128.ibm.com/developerworks/library/j-jtp03304/ |date=2007-01-08}} — Explains the changes JSR 133 made to the Java memory model.
* [http://www.cs.umd.edu/~pugh/java/memoryModel/ The Java Memory Model links]
<!-- * [http://www.cs.umd.edu/users/jmanson/java/popl05.pdf study explaining the new Java 5.0 memory model] broken 17/nov/08 -->
* {{JSR|133|JSR-133 webpage}}
* [http://www.cs.umd.edu/users/pugh/java/memoryModel/jsr-133-faq.html JSR-133 FAQ]{{ref-en}}
* [https://habrahabr.ru/company/golovachcourses/blog/221133/ Перевод JSR-133 FAQ]{{ref-ru}}
* [https://web.archive.org/web/20130925080251/http://g.oswego.edu/dl/jmm/cookbook.html JSR-133 implementation guide]

{{Java}}

[[Категория:Java]]
[[Категория:Управление конкурентными потоками]]