Действия ожидания происходят при вызове 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.4-C, как только произошла запись 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 класса Object (§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 > является корректным, если следующие утверждения верны:

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

Наблюдаемое поведение программы определяется конечными множествами внешних действий, которые может выполнять программа. Программа, которая, например, просто печатает "Привет" бесконечно, описывается множеством поведений, которые для любого неотрицательного целого числа i включают поведение печати "Привет" 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 final, которые по причинам совместимости должны быть изменены методами System.setIn, System.setOut и System.setErr. Мы называем эти поля защищенными от записи, чтобы отличить их от обычных полей final.

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