Модель памяти Java (англ. Java Memory Model, JMM) описывает поведение потоков в среде исполнения Java. Модель памяти — часть семантики языка Java, и описывает, на что может и на что не должен рассчитывать программист, разрабатывающий ПО не для конкретной Java-машины, а для Java в целом.
Исходная модель памяти Java (к которой, в частности, относится «потоколокальная память»), разработанная в 1995 году, считается неудачной: многие оптимизации невозможно провести, не потеряв гарантию безопасности кода. В частности, есть несколько вариантов написать многопоточную «одиночку»:[1]
- либо каждый акт доступа к одиночке (даже когда объект давно создан, и ничего уже не может измениться) будет вызывать межпоточную блокировку;
- либо при определённом стечении обстоятельств система выдаст недостроенного одиночку;
- либо при определённом стечении обстоятельств система создаст две одиночки;
- либо конструкция будет зависеть от особенностей поведения той или иной машины.
В J2SE 5.0 (30 сентября 2004) появилась новая модель памяти, разработанная через Java Community Process под названием JSR-133[2][3]. Она лучше отражала принципы работы современных процессоров и компиляторов, и другие языки брали идеи из модели Java. Основной вклад в её создание внесли Сарита Адве, Джереми Мейсон и Билл Пью[англ.][4].
Предпосылки
Суммиров вкратце
Перспектива
Язык программирования Java позволяет писать многопоточные программы. Поскольку Java может работать на самых разных процессорах и ОС, синхронизация потоков особенно затрудняется. Чтобы программист мог сделать какие-то выводы о поведении программ, разработчики Java решили чётко определить различные варианты поведения всех программ на Java.
На современных компьютерах код ради скорости выполняется не в том порядке, в котором написан. Перестановка выполняется компилятором, процессором и подсистемой памяти. На многопроцессорных машинах каждое ядро может иметь свой кэш, не синхронный с основной памятью. А значит, у разных процессоров могут быть одновременно разные значения одной и той же переменной. Когда потоки много взаимодействуют друг с другом, это обычно нежелательно: чтобы быть в курсе сделанного другим процессором, нужно много времени.
К тому же в однопоточной среде достаточно потребовать от системы «псевдопоследовательного» выполнения программы — наблюдателю, который видит только ввод-вывод, будет казаться, что все действия выполняются в том порядке, в котором они появились в программе, даже если это не так. Однако любому, кто сможет «заглянуть» в память компьютера — в том числе другому потоку — все эти «трюки» будут заметны. Рассмотрим два потока, которые одновременно выполняют такой код (x и y изначально нули).
| Поток 1 | Поток 2 |
|---|---|
| x = 1; | int r1 = y; |
| y = 2; | int r2 = x; |
Если нет перестановок, а поток 2 считал y=2, гарантированно должно быть x=1: ведь запись в x выполняется прежде, чем запись в y. С перестановкой оказывается возможна и, казалось бы, парадоксальная ситуация: r1=2, r2=0.
Такое поведение многопоточных программ модель JMM разрешает, но описывает, когда такие перестановки возможны. Таким образом, модель памяти Java накладывает ограничения на взаимодействие потоков, чтобы не потерять возможные оптимизации и в то же время дать возможность многопоточным программам вести себя надёжно и предсказуемо там, где это нужно. Программист может делать какие-либо заключения о том, в каком порядке выполняется код на многопоточной машине, даже несмотря на оптимизации, проводимые компилятором, процессором и кэшем.
Модель памяти
Суммиров вкратце
Перспектива
Правило № 1: однопоточные программы исполняются псевдопоследовательно. Это значит: в реальности процессор может выполнять несколько операций за такт, заодно изменив их порядок, однако все зависимости по данным остаются, так что поведение не отличается от последовательного.
Правило № 2: нет невесть откуда взявшихся значений. Чтение любой переменной (кроме не-volatile long и double, для которых это правило может не выполняться) выдаст либо значение по умолчанию (ноль), либо что-то, записанное туда другой командой.
И правило № 3: остальные события выполняются по порядку, если связаны отношением строгого частичного порядка «выполняется прежде» (англ. happens before).
«Выполняется прежде»
println выведет корректное значение.«Выполняется прежде» (англ. happens before) — отношение строгого частичного порядка (антирефлексивное, антисимметричное, транзитивное), введённое между атомарными командами (++ и -- не атомарны), придуманное Лесли Лэмпортом и не означающее «физически прежде». Оно значит, что вторая команда будет «в курсе» изменений, проведённых первой.
В частности, одно выполняется прежде другого для таких операций (список не исчерпывающий):
- Синхронизация и мониторы:
- Захват монитора (начало
synchronized, методlock) и всё, что после него в том же потоке. - Возврат монитора (конец
synchronized, методunlock) и всё, что перед ним в том же потоке.- Таким образом, оптимизатор может заносить строки в синхроблок, но не наружу.
- Возврат монитора и последующий захват другим потоком.
- Захват монитора (начало
- Запись и чтение:
- Любые зависимости по данным (то есть запись в любую переменную и последующее чтение её же) в одном потоке.
- Всё, что в том же потоке перед записью в
volatile-переменную, и сама запись. volatile-чтение и всё, что после него в том же потоке.- Запись в
volatile-переменную и последующее считывание её же[2][5]. Таким образом,volatile-запись делает с памятью то же, что возврат монитора, а чтение — то же, что захват[6]. А значит: если один поток записал вvolatile-переменную, а второй обнаружил это, всё, что предшествует записи, выполняется раньше всего, что идёт после чтения; см. иллюстрацию.- Для объектных переменных (например,
volatile List x;) столь сильные гарантии выполняются для ссылки на объект, но не для его содержимого.
- Для объектных переменных (например,
- Обслуживание объекта:
- Статическая инициализация и любые действия с любыми экземплярами объектов.
- Запись в
final-поля в конструкторе[7] и всё, что после конструктора. Как исключение из всеобщей транзитивности, это соотношение happens-before не соединяется транзитивно с другими правилами и поэтому может вызвать межпоточную гонку[8]. - Любая работа с объектом и
finalize().
- Обслуживание потока:
- Запуск потока и любой код в потоке.
- Зануление переменных, относящихся к потоку, и любой код в потоке.
- Код в потоке и
join(); код в потоке иisAlive() == false. interrupt()потока и обнаружение факта останова.
Влияние
Из-за повсеместного внедрения многопоточных и параллельных систем потребовался инструментарий с чёткой семантикой. Модель памяти Java стала первой попыткой разработать исчерпывающую модель межпоточного взаимодействия для крупного языка программирования[9].
В C++03 единственное замечание о многопоточности — для volatile-переменных не проводить никаких оптимизаций, связанных с ускорением доступа. Этого тоже не хватало, чтобы задействовать всю мощь переставляющего компилятора/процессора и не получить ошибку, связанную с внеочередным выполнением какой-то команды. Сходная модель памяти вошла в C++11[10].
См. также
- Модель памяти[англ.]
- Модель памяти Intel x86
- Модель памяти в языке Си
Примечания
Ссылки
Wikiwand - on
Seamless Wikipedia browsing. On steroids.