Действия ожидания происходят при вызове wait() или временных формах wait(long millisecs) и wait(long millisecs, int nanosecs).

Вызов wait(long millisecs) с параметром ноль или вызов wait(long millisecs, int nanosecs) с двумя параметрами ноль эквивалентен вызову wait().

Поток возвращается нормально из ожидания, если он возвращается без выбрасывания InterruptedException.

Пусть поток t выполняет метод wait на объекте m, а n — количество действий блокировки потоком t на m, не сопоставленных действиями разблокировки. Происходит одно из следующих действий:

Действия уведомления происходят при вызове методов notify и notifyAll.

Пусть поток t выполняет любой из этих методов на объекте m, а n — количество действий блокировки потоком t на m, не сопоставленных действиями разблокировки. Происходит одно из следующих действий:

Действия прерывания происходят при вызове Thread.interrupt, а также методов, определённых для его вызова, таких как ThreadGroup.interrupt.

Пусть t — поток, вызывающий u.interrupt для некоторого потока u, где t и u могут быть одинаковыми. Это действие приводит к установке состояния прерывания u в истинное.

Кроме того, если существует объект m, чей набор ожиданий содержит u, то u удаляется из набора ожиданий m. Это позволяет u возобновить действие ожидания, в результате чего это ожидание, после повторного блокирования монитора m, выбросит InterruptedException.

Вызовы Thread.isInterrupted могут определять состояние прерывания потока. Метод static Thread.interrupted может вызываться потоком для наблюдения и сброса собственного состояния прерывания.

Вышеуказанные спецификации позволяют определить несколько свойств, связанных с взаимодействием ожиданий, уведомлений и прерываний.

Если поток прерывается и получает уведомление во время ожидания, он может:

Поток не может сбросить свой статус прерывания и нормально завершить вызов wait.

Аналогично, уведомления не могут быть утеряны из-за прерываний. Предположим, что набор s потоков находится в наборе ожиданий объекта m, и другой поток выполняет notify для m. Тогда либо:

Обратите внимание, что если поток прерывается и пробуждается через notify, и этот поток завершается из wait, сбросив InterruptedException, то какой-то другой поток в наборе ожиданий должен получить уведомление.

Память, которая может быть общей для нескольких потоков, называется общей памятью или кучей памяти.

Все поля экземпляров, поля static и элементы массивов хранятся в куче памяти. В этой главе мы используем термин переменная для обозначения как полей, так и элементов массива.

Локальные переменные (§14.4), формальные параметры методов (§8.4.1) и параметры обработчиков исключений (§14.20) никогда не являются общими для потоков и не затрагиваются моделью памяти.

Два обращения к (чтения или записи в) одной и той же переменной считаются конфликтующими, если хотя бы одно из обращений является записью.

Межпотоковое действие — это действие, выполняемое одним потоком, которое может быть обнаружено или непосредственно повлиять на другой поток. Существует несколько видов межпотоковых действий, которые может выполнять программа:

Данное описание касается только межпотоковых действий. Нам не нужно беспокоиться о внутрипотоковых действиях (например, сложении двух локальных переменных и сохранении результата в третьей локальной переменной). Как уже упоминалось, все потоки должны подчиняться правильным внутрипотоковым семантикам для Java-программ. Обычно мы будем кратко называть межпотоковые действия просто действиями.

Действие a описывается кортежем < t, k, v, u >, состоящим из:

Кортеж внешнего действия содержит дополнительный компонент, который содержит результаты внешнего действия, как они воспринимаются потоком, выполняющим действие. Это может быть информация о успехе или неудаче действия, и любые значения, прочитанные действием.

Параметры внешнего действия (например, какие байты записываются в какой сокет) не являются частью кортежа внешнего действия. Эти параметры устанавливаются другими действиями внутри потока и могут быть определены путем изучения внутрипотоковой семантики. Они не обсуждаются в явном виде в модели памяти.

В бесконечных выполнениях не все внешние действия наблюдаемы. Бесконечные выполнения и наблюдаемые действия обсуждаются в §17.4.9.

Среди всех межпотоковых действий, выполняемых каждым потоком t, порядок программы потока t — это общий порядок, который отражает порядок, в котором эти действия были бы выполнены согласно внутрипотоковой семантике t.

Набор действий последовательно согласован, если все действия происходят в общем порядке (порядке выполнения), согласованном с порядком программы, и, кроме того, каждое чтение r переменной v видит значение, записанное записью w в v таким образом, что:

Последовательная согласованность — это очень сильная гарантия, которая дается относительно видимости и порядка в выполнении программы. В последовательно согласованном выполнении существует общий порядок всех отдельных действий (таких как чтения и записи), который согласуется с порядком программы, и каждое отдельное действие является атомным и немедленно видно каждому потоку.

Если программа не имеет гонок данных, то все выполнения программы будут казаться последовательно согласованными.

Последовательная согласованность и/или отсутствие гонок данных все равно допускают ошибки, возникающие из-за групп операций, которые должны восприниматься как атомные, но таковыми не являются.

Если бы мы использовали последовательную согласованность в качестве нашей модели памяти, многие из обсуждавшихся нами оптимизаций компилятора и процессора были бы незаконными. Например, в трассировке в Таблице 17.3, как только произошла запись 3 в p.x, последующие чтения этой позиции должны будут увидеть это значение.

Каждое выполнение имеет порядок синхронизации. Порядок синхронизации — это общий порядок всех действий синхронизации в данном выполнении. Для каждого потока t порядок синхронизации действий синхронизации (§17.4.2) в t согласован с порядком выполнения программы (§17.4.3) потока t.

Действия синхронизации вызывают отношение synchronized-with на действиях, определяемое следующим образом:

Источник ребра synchronizes-with называется освобождением, а пункт назначения — приобретением.

Две операции могут быть упорядочены отношением happens-before. Если одна операция happens-before другой, то первая видна и упорядочена перед второй.

Если у нас есть две операции x и y, мы записываем hb(x, y) для обозначения того, что x происходит до y.

Методы класса wait (§17.2.1) имеют связанные с ними операции блокировки и разблокировки; их отношения happens-before определяются этими связанными операциями.

Следует отметить, что наличие отношения happens-before между двумя операциями не обязательно означает, что они должны выполняться в этом порядке в реализации. Если переупорядочение приводит к результатам, согласующимся с законным выполнением, то это не является незаконным.

Например, запись значения по умолчанию в каждое поле объекта, созданного потоком, не обязательно должна произойти до начала этого потока, если ни один чтение никогда не наблюдает этот факт.

Более конкретно, если две операции имеют отношение happens-before, они не обязательно должны казаться произошедшими в этом порядке для любого кода, с которым они не разделяют отношение happens-before. Например, записи в одном потоке, которые находятся в гонке данных с чтениями в другом потоке, могут показаться не в том порядке для этих чтений.

Отношение happens-before определяет, когда происходят гонки данных.

Набор синхронизационных рёбер, S, является достаточным, если это минимальный набор, такой что транзитивное замыкание S с порядком программы определяет все рёбра happens-before в выполнении. Этот набор единственный.

Из вышеизложенных определений следует, что:

Когда программа содержит два конфликтующих доступа (§17.4.1), которые не упорядочены отношением happens-before, она содержит гонку данных.

Семантика операций, отличных от межпотоковых действий, таких как чтение длин массивов (§10.7), выполнение проверок типов (§5.5, §15.16) и вызовы виртуальных методов (§15.12), напрямую не затрагиваются гонками данных.

Поэтому гонка данных не может привести к неправильному поведению, например, возвращению неправильной длины массива.

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

Если программа правильно синхронизирована, все выполнения программы будут казаться последовательно согласованными (§17.4.3).

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

Программа должна быть правильно синхронизирована, чтобы избежать видов неинтуитивного поведения, которое может наблюдаться, когда код переупорядочен. Использование правильной синхронизации не гарантирует, что общее поведение программы является правильным. Однако его использование позволяет программисту рассуждать о возможных поведении программы простым способом; поведение правильно синхронизированной программы гораздо меньше зависит от возможных переупорядочений. Без правильной синхронизации возможны очень странные, запутанные и неинтуитивные поведения.

Мы говорим, что чтение r переменной v может наблюдать запись w в v, если в частичном порядке happens-before следа выполнения:

Неформально, чтение r разрешено видеть результат записи w, если нет упорядочения happens-before, которое может этого воспрепятствовать.

Набор действий A называется согласованным по happens-before, если для всех чтений r в A, где W(r) — действие записи, увиденное r, неверно, что либо hb(r, W(r)), либо существует запись w в A такая, что w.v = r.v и hb(W(r), w) и hb(w, r).

В наборе действий, согласованном по happens-before, каждое чтение видит запись, которую оно разрешено видеть по упорядочению happens-before.

1: B = 1;
3: A = 2;
2: r2 = A;  // sees initial write of 0
4: r1 = B;  // sees initial write of 0

1: r2 = A;  // sees write of A = 2
3: r1 = B;  // sees write of B = 1
2: B = 1;
4: A = 2;

Выполнение E описывается кортежем < P, A, po, so, W, V, sw, hb >, состоящим из:

Обратите внимание, что элементы синхронизируется-с и происходит-до однозначно определяются другими компонентами выполнения и правилами для корректных выполнений (§17.4.7).

Выполнение является последовательным относительно происходит-до, если его набор действий является последовательным относительно происходит-до (§17.4.5).

Мы рассматриваем только корректные выполнения. Выполнение E = < P, A, po, so, W, V, sw, hb > является корректным, если выполнены следующие условия:

Для программ, которые всегда завершаются в некоторый ограниченный конечный период времени, их поведение можно понять (неформально) просто в терминах их допустимых выполнений. Для программ, которые могут не завершиться за ограниченное время, возникают более тонкие вопросы.

Наблюдаемое поведение программы определяется конечными наборами внешних действий, которые программа может выполнить. Например, программа, которая просто постоянно печатает "Hello", описывается набором поведений, который для любого неотрицательного целого числа i включает поведение печати "Hello" i раз.

Завершение не моделируется явно как поведение, но программу можно легко расширить, чтобы она генерировала дополнительное внешнее действие executionTermination, которое происходит, когда все потоки завершились.

Мы также определяем специальное действие hang. Если поведение описывается набором внешних действий, включающим действие hang, это указывает на поведение, при котором после наблюдения внешних действий программа может выполняться неограниченное время без выполнения дополнительных внешних действий или завершения. Программы могут зависнуть, если все потоки заблокированы или если программа может выполнить неограниченное количество действий без выполнения каких-либо внешних действий.

Поток может быть заблокирован в различных обстоятельствах, таких как попытка получить блокировку или выполнить внешнее действие (например, чтение), которое зависит от внешних данных.

Выполнение может привести к тому, что поток будет заблокирован на неопределённое время, и выполнение не завершится. В таких случаях действия, сгенерированные заблокированным потоком, должны состоять из всех действий, сгенерированных этим потоком вплоть до и включая действие, которое привело к блокировке потока, и никаких действий, которые были бы сгенерированы потоком после этого действия.

Для анализа наблюдаемых поведений нам нужно говорить о множествах наблюдаемых действий.

Если O является множеством наблюдаемых действий для выполнения E, то множество O должно быть подмножеством действий E, A, и должно содержать только конечное число действий, даже если A содержит бесконечное число действий. Кроме того, если действие y находится в O, и либо hb(x, y), либо so(x, y), то x находится в O.

Обратите внимание, что набор наблюдаемых действий не ограничивается внешними действиями. Скорее, только внешние действия, которые находятся в наборе наблюдаемых действий, считаются наблюдаемыми внешними действиями.

Поведение B является допустимым поведением программы P тогда и только тогда, когда B является конечным набором внешних действий и либо:

Обратите внимание, что поведение B не описывает порядок наблюдения внешних действий в B, но другие (внутренние) ограничения на то, как генерируются и выполняются внешние действия, могут накладывать такие ограничения.

Пусть o — объект, а c — конструктор для o, в котором записывается final поле f. Действие freeze для final поля f объекта o происходит при завершении конструктора c, будь то нормальное завершение или аварийное.

Обратите внимание, что если один конструктор вызывает другой конструктор, и вызванный конструктор устанавливает final поле, действие freeze для final поля происходит в конце вызываемого конструктора.

Для каждого выполнения поведение чтений определяется двумя дополнительными частичными порядками: цепочкой ссылок dereferences() и цепочкой памяти mc(), которые считаются частью выполнения (и, следовательно, фиксированы для любого конкретного выполнения). Эти частичные порядки должны удовлетворять следующим ограничениям (которые не обязательно имеют единственное решение):

Учитывая запись w, действие freeze f, действие a (которое не является чтением final поля), чтение r₁ final поля, замороженного f, и чтение r₂ такое, что hb(w, f), hb(f, a), mc(a, r₁), и dereferences(r₁, r₂), то при определении значений, которые может увидеть r₂, мы учитываем hb(w, r₂). (Этот порядок happens-before не транзитивно закрывается с другими порядками happens-before).

Обратите внимание, что порядок dereferences рефлексивен, и r₁ может быть таким же, как r₂.

Для чтений final полей, единственные записи, которые считаются предшествующими чтению final поля, — это те, которые получены через семантику final поля.

Чтение final поля объекта внутри потока, который строит этот объект, упорядочено относительно инициализации этого поля внутри конструктора обычными правилами happens-before. Если чтение происходит после того, как поле установлено в конструкторе, оно видит значение, присвоенное final полю, иначе — значение по умолчанию.

В некоторых случаях, таких как десериализация, системе потребуется изменить поля final объекта после его создания. Поля final могут быть изменены с помощью рефлексии и других механизмов, зависящих от реализации. Единственный шаблон, в котором это имеет разумную семантику, заключается в том, что объект создаётся, а затем поля final объекта обновляются. Объект не должен быть доступен другим потокам, и поля final не должны считываться, пока не будут завершены все обновления полей final объекта. Замораживание поля final происходит как в конце конструктора, в котором устанавливается поле final, так и сразу после каждого изменения поля final с помощью рефлексии или других специальных механизмов.

Даже тогда есть ряд осложнений. Если поле final инициализируется выражением константы времени компиляции (§15.28) в объявлении поля, изменения поля final могут не быть замечены, так как использование этого поля final заменяется на значение константного выражения во время компиляции.

Другая проблема заключается в том, что спецификация допускает агрессивную оптимизацию полей final. Внутри потока разрешается переупорядочить чтение поля final с изменениями поля final, которые не происходят в конструкторе.

class A {
    final int x;
    A() { 
        x = 1; 
    } 

    int f() { 
        return d(this,this); 
    } 

    int d(A a1, A a2) { 
        int i = a1.x; 
        g(a1); 
        int j = a2.x; 
        return j - i; 
    }

    static void g(A a) { 
        // uses reflection to change a.x to 2 
    } 
}

Реализация может предоставить способ выполнения блока кода в final-безопасном контексте. Если объект создаётся в final-безопасном контексте, чтение поля final этого объекта не будет переупорядочено с изменениями этого поля final, которые происходят в этом final-безопасном контексте.

final-безопасный контекст имеет дополнительные защиты. Если поток увидел неправильно опубликованную ссылку на объект, который позволяет потоку увидеть значение по умолчанию поля final, а затем, в пределах final-безопасного контекста, считывает правильно опубликованную ссылку на объект, ему гарантированно будет показано правильное значение поля final. В формализме код, выполняемый в пределах final-безопасного контекста, рассматривается как отдельный поток (только для целей семантики поля final).

В реализации компилятор не должен перемещать доступ к полю final в final-безопасный контекст или из него (хотя он может перемещаться вокруг выполнения такого контекста, при условии, что объект не создаётся в этом контексте).

Одно место, где использование final-безопасного контекста было бы уместно, — это в исполнителе или пуле потоков. Выполняя каждый Runnable в отдельном final-безопасном контексте, исполнитель мог бы гарантировать, что неверный доступ одного Runnable к объекту o не удалит гарантии поля final для других Runnable, обрабатываемых тем же исполнителем.

Обычно поле, которое является final и static, не может быть изменено. Однако, поля System.in, System.out и System.err — это static защищенные от записи поля, которые по причинам совместимости должны быть изменяемы методами System.setIn, System.setOut и System.setErr. Мы называем эти поля защищенными от записи, чтобы отличить их от обычных полей final.

Компилятор должен по-разному обрабатывать эти поля по сравнению с другими полями final. Например, чтение обычного поля final «иммунно» к синхронизации: барьер, связанный с блокировкой или считыванием volatile, не должен влиять на значение, считанное из поля final. Поскольку значение защищенных от записи полей может изменяться, события синхронизации должны на них влиять. Поэтому семантика предписывает обрабатывать эти поля как обычные поля, которые нельзя изменить кодом пользователя, если этот код пользователя не находится в классе System.