Глава 17. Потоки и блокировки

Действия ожидания происходят при вызове 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 — поток, вызывающий метод .interrupt для некоторого потока u, где t и u могут быть одинаковыми. Это действие устанавливает состояние прерывания u в истинное.

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

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

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

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

Поток не может сбросить свой статус прерывания и нормально вернуться из вызова 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 называется освобождением, а пункт назначения — получением.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 >, включающим:

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

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

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

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

Наблюдаемое поведение программы определяется конечными наборами внешних действий, которые может выполнить программа. Например, программа, которая просто бесконечно печатает "Hello", описывается набором поведений, включающих в себя поведение печати "Hello" 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, фиксацию 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.29) в объявлении поля, изменения поля 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.